name: schema
on:
  push:
    branches:
      - master
  pull_request:
    branches-ignore:
      - i18n_master

permissions:
  contents: read

jobs:
  schema:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:10.10
        ports: ["5432:5432"]
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
        env:
          POSTGRES_USER: consul
          POSTGRES_PASSWORD: ""
    env:
      PGUSER: consul
      POSTGRES_HOST: postgres
    steps:
      - uses: actions/checkout@v2
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
      - name: Copy secrets and database files
        run: for i in config/*.example; do cp "$i" "${i/.example}"; done
      - name: Backup schema file
        run: cp db/schema.rb db/commited_schema.rb
      - name: Setup database
        run: bundle exec rake db:create db:migrate
      - name: Check the commited schema is correct
        run: diff db/schema.rb db/commited_schema.rb

Verify the schema.rb integrity when running our CI
Verify the schema.rb integrity when running our CI

In the past, we've run into situations where we commited a version of
the schema.rb to version control which wasn't in sync with what you get
when you create the database and run the migrations. This is something
that might happen if you're working on different branches at the same
time, run the migrations in all those branches, and then commit the
current status of your database to your current branch. That will result
in a schema file which contains the database changes done in all these
branches instead of just the current one.

Although this hasn't happened to us for years, we see it happening
sometimes in other COSUL installations, and there's always a chance that
we make a mistake and do it again.

Until now, it wasn't a big deal because the installer sets up the
database by running `db:create db:migrate`, which runs the migrations
instead of using the `schema.rb` file.

However, we're going to add multitenancy using the Aparment gem, and
this gem uses the `schema.rb` file when creating a new schema for a new
tenant [1]. If the `schema.rb` file contains changes that shouldn't be
there, this will lead to different database schemas having different
tables and/or columns and future migrations might crash on production
when applied to some of these schemas. In other words, this mistake
could now result in a disastrous situation.

To help preventing that, we're adding a CI workflow that checks the
current `schema.rb` file is in sync with the database migrations.

[1] https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f#7e97
