Add river validate command to check for unapplied migrations
#170
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
brandur
force-pushed
the
brandur-river-validate
branch
10 times, most recently
from
31c3470
to
353e525
Compare
This one's a feature request from a few months from [1] in which we add a `river validate` command which fails with a non-zero exit code in case there are unapplied migrations in the target database. As described in the original discussion, this could be used in a project's CI to detect and fail in the presence of a new migration that was part of a River version update (giving people an easy way to check programmatically so that upgrades aren't as dependent on a user successfully seeing a new migration in the changelog). [1] #68
brandur
force-pushed
the
brandur-river-validate
branch
from
353e525
to
c7bbf01
Compare
brandur
commented
Jan 22, 2024
| @@ -2,7 +2,7 @@ module github.com/riverqueue/river/cmd/river | |||
|
|
|||
| go 1.21.4 | |||
|
|
|||
| // replace github.com/riverqueue/river => ../.. | |||
| replace github.com/riverqueue/river => ../.. | |||
There was a problem hiding this comment.
Uncommented to demonstrate that the whole package works, but I'll have to unwind this as I'm cutting a release. We have steps in development.md that'll theoretically work for this situation ...
|
Great, thanks! |
brandur
added a commit
that referenced
this pull request
Jan 22, 2024
Here, as proposed by the new release instructions in #169, tee up some changes for 0.0.17, updating `CHANGELOG.md` with the new section and modifying `go.mod` files to point to the new release. Unfortunate note no. 1: the `go.mod` files change from 0.0.15 to 0.0.17 instead of starting at 0.0.16 because I accidentally botched the last release by not pushing the `go.mod` changes. Hopefully this new process will correct that so it doesn't happen again. Unfortunate note no. 2: As noted in #169, we expect the build to fail here because `go.mod` files point to a version that doesn't have a tag yet. The new `river validate` is included here (#170) so I'm also going to try a two-phase release by tagging all submodules except for `./cmd/river` with 0.0.17 first, then modifying that submodule to point to the new 0.0.17 in other modules, then do a cut and release for it separately. Kind of a pain, but as discussed at length before, this seems to be the least bad of a bunch of suboptimal options.
brandur
added a commit
that referenced
this pull request
Jan 23, 2024
Here, as proposed by the new release instructions in #169, tee up some changes for 0.0.17, updating `CHANGELOG.md` with the new section and modifying `go.mod` files to point to the new release. Unfortunate note no. 1: the `go.mod` files change from 0.0.15 to 0.0.17 instead of starting at 0.0.16 because I accidentally botched the last release by not pushing the `go.mod` changes. Hopefully this new process will correct that so it doesn't happen again. Unfortunate note no. 2: As noted in #169, we expect the build to fail here because `go.mod` files point to a version that doesn't have a tag yet. The new `river validate` is included here (#170) so I'm also going to try a two-phase release by tagging all submodules except for `./cmd/river` with 0.0.17 first, then modifying that submodule to point to the new 0.0.17 in other modules, then do a cut and release for it separately. Kind of a pain, but as discussed at length before, this seems to be the least bad of a bunch of suboptimal options.
brandur
added a commit
that referenced
this pull request
Jan 23, 2024
Follow up #172 by also updating the River CLI to version 0.0.17. This must be done as a separate step because the River CLI module depends on the main module, and therefore the 0.0.17 tag for the main module must exist before we can lock to it from the River CLI. The rough process here was to: * Remove the `replace` statement added in #170 to demonstrate that the new `river validate` command worked. * Modify `./cmd/river/go.mod`'s River dependency to use v0.0.17. * Run `go mod tidy` to update `go.sum` and bump the version of the other River subdependencies too.
brandur
added a commit
that referenced
this pull request
Jan 23, 2024
Follow up #172 by also updating the River CLI to version 0.0.17. This must be done as a separate step because the River CLI module depends on the main module, and therefore the 0.0.17 tag for the main module must exist before we can lock to it from the River CLI. The rough process here was to: * Remove the `replace` statement added in #170 to demonstrate that the new `river validate` command worked. * Modify `./cmd/river/go.mod`'s River dependency to use v0.0.17. * Run `go mod tidy` to update `go.sum` and bump the version of the other River subdependencies too. After merging this, I'll add and push one last tag: export VERSION=v0.0.17 git tag cmd/river/$VERSION -m "release cmd/river/$VERSION" git push --tags
brandur
added a commit
that referenced
this pull request
Jan 23, 2024
Follow up #172 by also updating the River CLI to version 0.0.17. This must be done as a separate step because the River CLI module depends on the main module, and therefore the 0.0.17 tag for the main module must exist before we can lock to it from the River CLI. The rough process here was to: * Remove the `replace` statement added in #170 to demonstrate that the new `river validate` command worked. * Modify `./cmd/river/go.mod`'s River dependency to use v0.0.17. * Run `go mod tidy` to update `go.sum` and bump the version of the other River subdependencies too. After merging this, I'll add and push one last tag: export VERSION=v0.0.17 git tag cmd/river/$VERSION -m "release cmd/river/$VERSION" git push --tags
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.
This one's a feature request from a few months from [1] in which we add
a
river validatecommand which fails with a non-zero exit code in casethere are unapplied migrations in the target database. As described in
the original discussion, this could be used in a project's CI to detect
and fail in the presence of a new migration that was part of a River
version update (giving people an easy way to check programmatically so
that upgrades aren't as dependent on a user successfully seeing a new
migration in the changelog).
[1] #68