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

Conversation

brandur
Copy link
Contributor

@brandur brandur commented Aug 18, 2024

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
Copy link
Contributor Author

brandur commented Aug 18, 2024

@bgentry Workspaces definitely have their warts, but for this kind of change that changes the API across the River/River CLI boundary, it's really nice (1) not having to mess with any replace statements, and (2) being able to run tests from anywhere like:

$ go test ./cmd/river/rivercli -run TestMigrateList

I'm hoping we can figure out how to make this work to keep the DX improvements if nothing else.

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
Copy link
Contributor Author

brandur commented Aug 20, 2024

Thanks!

@brandur brandur merged commit 94b0a78 into master Aug 20, 2024
14 checks passed
@brandur brandur deleted the brandur-migrate-list branch August 20, 2024 03:07
brandur added a commit that referenced this pull request Aug 20, 2024
Prepare release v0.11.4 to fix the bad release in v0.11.3 that was
causing the CLI to become uninstalled as described in #538. The release
script has now been updated in #534 so that the `rivershared` dependency
also gets properly bumped.

I'm also going to try to the `[skip ci]` tag during this release to
hopefully prevent bad caching in the Go proxy and make the release
available sooner.

Fixes #538.

[skip ci]
@brandur brandur mentioned this pull request Aug 20, 2024
brandur added a commit that referenced this pull request Aug 20, 2024
Prepare release v0.11.4 to fix the bad release in v0.11.3 that was
causing the CLI to become uninstalled as described in #538. The release
script has now been updated in #534 so that the `rivershared` dependency
also gets properly bumped.

I'm also going to try to the `[skip ci]` tag during this release to
hopefully prevent bad caching in the Go proxy and make the release
available sooner.

Fixes #538.

[skip ci]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants