Closed brandur closed 3 weeks ago
@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.
Thanks!
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: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 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
), but despite that, it should give us reasonable assuredness for now.