-
Notifications
You must be signed in to change notification settings - Fork 90
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@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
I'm hoping we can figure out how to make this work to keep the DX improvements if nothing else. |
brandur
force-pushed
the
brandur-migrate-list
branch
from
August 18, 2024 21:24
98224af
to
9409892
Compare
bgentry
approved these changes
Aug 20, 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
force-pushed
the
brandur-migrate-list
branch
from
August 20, 2024 02:59
9409892
to
8be427d
Compare
Thanks! |
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]
Merged
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here, add a new
migrate-list
command to the River CLI. It prints theversions and names of available migrations along with an indicator as to
the current state of the database:
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 wayto figure out what migrations actually existed before you ran it.
migrate-list
currently requires a--database-url
, but later I wantto 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 asan alternative to
--database-url
. This will also be useful formigrate-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
), butdespite that, it should give us reasonable assuredness for now.