Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add migrate-list subcommand that lists available migrations #534

Merged
merged 1 commit into from
Aug 20, 2024

Commits on Aug 20, 2024

  1. Add migrate-list subcommand that lists available migrations

    Here, add a new `migrate-list` command to the River CLI. It prints the
    versions and names of available migrations along with an indicator as to
    the current state of the database:
    
        $ go run ./cmd/river migrate-list --database-url postgres:///river_dev
          001 create river migration
          002 initial schema
          003 river job tags non null
          004 pending and more
        * 005 migration unique client
    
    It's pretty far from a high priority feature, but I started it a few
    weeks ago and I figured I may as well finish it. I started because I
    realized that despite having a `migrate-get` command, there was no way
    to figure out what migrations actually existed before you ran it.
    
    `migrate-list` currently requires a `--database-url`, but later I want
    to put in an alternate version that can work without one too. A
    complication with that is that I want to build a system that can hint on
    the desired database system (currently detected based off URL scheme) in
    case we add SQLite later. I'm thinking that we'll be able to add an
    option like `--database postgres` or `--engine postgres` that can act as
    an alternative to `--database-url`. This will also be useful for
    `migrate-get`, which also currently has no answer for this.
    
    I bring in a test convention for CLI commands so we can start trying to
    check with more authority that things like expected output stay stable.
    (Previously, we weren't testing commands except to vet that they will
    run successfully in CI.) This approach uses mocks because we still have
    no way of reusing database-based testing infrastructure outside the main
    package (eventually some of it should go into `rivershared`), but
    despite that, it should give us reasonable assuredness for now.
    brandur committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    8be427d View commit details
    Browse the repository at this point in the history