Add CI check that db/schema.rb matches result of migrations #245
Comments
tom93
added a commit
that referenced
this issue
Jan 5, 2024
This workflow runs the tests and is a replacement for our previous Travis CI setup (.travis.yml), which we no longer use due to #147. The commands to run the install scripts and the tests are loosely based on .travis.yml, with several updates and fixes. The workflow's structure as a whole is based on GitHub Action's Ruby on Rails CI template. The most notable change compared to .travis.yml is that we are dropping the `--skip-update` option when running install.bash. That option skips a couple of steps: `bundle install`, migrate.bash, whenever.bash. The new workflow can work without those steps, but it's fragile: the `bundle install` step is only safe to skip because we pass `bundler-cache: true` to ruby/setup-ruby; if we disable the cache then ruby/setup-ruby won't run `bundle install` and the build will fail. So it's better to always run `bundle install` explicitly (running it twice doesn't do any harm, and it's very fast the second time). Dropping `--skip-updates` also causes migrate.bash to be executed, which is a good thing because it exercises the migration code. It also allows us to drop the `rake db:test:load` step. (Creating the database by loading the schema is fast, but db/schema.rb is slightly incomplete: it doesn't include the index "index_users_on_username" because of a Rails limitation. Since we are running the migrations anyway, we might as well use the database created by them.) Later on we will also add a check that reports an error if the schema dumped after running the migrations has any differences compared to the schema in the repository (#245). Running whenever.bash is quick and doesn't do any harm. Another notable change is that we are adding a "lint" job that runs "standardrb" (recently added in #215). Currently this doesn't do much because .standard.yml ignores all the files. There are a couple of differences compared to the GitHub Actions Ruby on Rails CI template[1]: - The template only runs the job on push/pull-request for branch "master", but we run the job for all branches because we want to be able to push commits and have them tested without having to open a pull request. - The template runs on ubuntu-latest, but we use ubuntu-20.04 because the build currently fails on ubuntu-latest. - The template doesn't have a Docker health check for the "postgres" service (to wait until it starts). We use a health check based on [2], but with a slightly different command[3]. - We have a "redis" service (based on [4]). - We have a custom install script. - The template uses bin/rails etc., which we don't have yet. - The template uses db:schema:load, which we don't need (see discussion of db:test:load above). - The template has pretty step names, which we don't bother with. - The template's "lint" job uses bundler-audit, brakeman, and rubocop. We use standardrb (which wraps rubocop), and will add bundler-audit later (#244). [1] https://github.com/actions/starter-workflows/blob/c31fe3d5d44d7cb4c912f4c3213f7b4610f13ea2/ci/rubyonrails.yml [2] https://docs.github.com/en/actions/using-containerized-services/creating-postgresql-service-containers#running-jobs-directly-on-the-runner-machine [3] We pass `-U postgres` to pg_isready to suppress error messages: pg_isready works even if the username is invalid, however it causes the following error message to appear repeatedly in the postgres container log (displayed in the "Stop containers" step): `FATAL: role "root" does not exist` [4] https://docs.github.com/en/actions/using-containerized-services/creating-redis-service-containers#running-jobs-directly-on-the-runner-machine Co-authored-by: Tom Levy <[email protected]>
tom93
added a commit
that referenced
this issue
Jan 5, 2024
This workflow runs the tests and is a replacement for our previous Travis CI setup (.travis.yml), which we no longer use due to #147. The commands to run the install scripts and the tests are loosely based on .travis.yml, with several updates and fixes. The overall structure of the workflow is based on the GitHub Actions Ruby on Rails CI template[1]. The most notable change compared to .travis.yml is that we are dropping the `--skip-update` option when running install.bash. That option skips a couple of steps: `bundle install`, migrate.bash, whenever.bash. The new workflow can run without those steps, but it's fragile: the `bundle install` step is only safe to skip because we pass `bundler-cache: true` to ruby/setup-ruby; if we disable the cache then ruby/setup-ruby won't run `bundle install` and the build will fail. So it's better to always run `bundle install` explicitly (running it twice doesn't do any harm, and it's very fast the second time). Dropping `--skip-updates` also causes migrate.bash to be executed, which is a good thing because it exercises the migration code. It also allows us to drop the `rake db:test:load` step. (Creating the database by loading the schema is fast, but db/schema.rb is slightly incomplete: it doesn't include the index "index_users_on_username" because of a Rails limitation. Since we are running the migrations anyway, we might as well use the database created by them.) Later on we will also add a check that reports an error if the schema dumped after running the migrations has any differences compared to the schema in the repository (#245). Running whenever.bash is quick and doesn't do any harm. Another notable change is that we are adding a "lint" job that runs "standardrb" (recently added in #215). Currently this doesn't do much because .standard.yml ignores all the files. Compared to the GitHub Actions Ruby on Rails CI template[1], there are a couple of differences: - The template only runs the job on push/pull-request for branch "master", but we run the job for all branches because we want to be able to push commits and have them tested without having to open a pull request. - The template runs on ubuntu-latest, but we use ubuntu-20.04 because the build currently fails on ubuntu-latest. - The template doesn't have a Docker health check for the "postgres" service (to wait until it starts). We use a health check based on [2], but with a slightly different command[3]. - We have a "redis" service (based on [4]). - We have a custom install script. - The template uses bin/rails etc., which we don't have yet. - The template uses db:schema:load, which we don't need (see discussion of db:test:load above). - The template has pretty step names, which we don't bother with. - The template's "lint" job uses bundler-audit, brakeman, and rubocop. We use standardrb (which wraps rubocop), and will add bundler-audit later (#244). [1] https://github.com/actions/starter-workflows/blob/c31fe3d5d44d7cb4c912f4c3213f7b4610f13ea2/ci/rubyonrails.yml [2] https://docs.github.com/en/actions/using-containerized-services/creating-postgresql-service-containers#running-jobs-directly-on-the-runner-machine [3] We pass `-U postgres` to pg_isready to suppress error messages: pg_isready works even if the username is invalid, however it causes the following error message to appear repeatedly in the postgres container log (displayed in the "Stop containers" step): `FATAL: role "root" does not exist` [4] https://docs.github.com/en/actions/using-containerized-services/creating-redis-service-containers#running-jobs-directly-on-the-runner-machine Co-authored-by: Tom Levy <[email protected]>
tom93
added a commit
that referenced
this issue
Jan 5, 2024
tom93
added a commit
that referenced
this issue
Jan 5, 2024
tom93
added a commit
that referenced
this issue
Jan 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: