Add river validate subcommand

[dhermes]

Reading https://riverqueue.com/docs/migrations I'm struck by the fact that it may be hard (over time) to figure out if the version of the schema I'm running in my database matches the schema expected by the version river that I've got in my go.mod / go.sum.

I also think having river validate would make it much easier for teams like mine to integrate this into our existing migrations workflow. I.e. we could run river validate in CI and during development and detect if our existing migrations sequence needs to be updated.

(I don't think it'd be the end of the world to add river migrate-up during deploy right next to our migrate up command. However, having the two work together during development is preferable to having two "migrations managers" running during our deploys.)

[brandur]

This is a good idea. I'm going to be refactoring the migrations component so it can be a Go API, and I'll take a look at this after.

We're going to start tracking feature requests as GitHub discussions, so I'm going to convert this issue to one.

Anyone finding this: use the upvote reactji if you'd find this useful to help us prioritize.

[dhermes]

I have an update here: my team integrated river over the last week and we added some validation in a GitHub Actions workflow. It relies on the fact that we have a schema snapshot available at all times (and updated in all PRs) living at migrations/latest.sql.

The check that runs in the CI job is (approximately):

make restart-postgresql

river migrate-down \
  --max-steps 1000 \
  --database-url 'postgres://...?search_path=riverqueue'

river migrate-up \
  --database-url 'postgres://...?search_path=riverqueue'

pg_dump \
  --no-owner --no-privileges --schema-only \
  'postgres://...' \
  > ./migrations/latest.sql

# Make sure the schema is unchanged
git diff HEAD ./migrations/latest.sql

And we only run it (in GitHub Actions) if:

on:
  pull_request:
    branches:
      - main
    paths:
      - .github/workflows/riverqueue-check-migrations.yaml
      - vendor/github.com/riverqueue/**

So this is making sure that our schema (in migrations/latest.sql) matches what river wants to be present.

---

To actually make sure the river schema IS PRESENT in our codebase's migrations/latest.sql, I just pulled in the migrations in github.com/riverqueue/river/rivermigrate/migration/*.up.sql into our existing migration process. (With a few manual modifications to prepend the riverqueue. schema to tables / indexes / enums / functions / etc.)

[brandur]

@dhermes Thanks for checking back in on this and the detailed information. My intention is still to provide something like river validate, but I wanted to get some other migration refactors in first because that was causing the code related to both migrations and the CLI to be heavily in flux. Finally landed all of that last night — I'm going to tackle this next.

[brandur]

@dhermes The lastest version of River/River CLI, 0.0.17, just shipped with river validate. See changelog.

[dhermes]

Awesome thanks! Just ditched our migrate-down + migrate-up validation rig and put in validate.

[brandur]

Great!

I'm a bit of an amateur GitHub discussions user still and not sure what the right workflow patterns are with it, but since this is resolve, I'm going to try closing this discussion so that it hopefully loses prominence on the top-level topics list.