PostgreSQL 13 will reach its end-of-life on November 13, 2025. So we're
upgrading before that happens.
We're also upgrading to PostgreSQL 14 in our CI. In this case, we're
using the default distribution (Trixie, as of October 2025); it doesn't
affect the development or production environments, so it's OK if use the
default one.
Using ubuntu-latest might result in incompatibilities when this image
changes to a different version of Ubuntu. For example, the Ubuntu 24.04
image no longer includes imagemagick, meaning that we'll have to install
it manually when using Ubuntu 24.04.
We're using version 13 because it's the one included in Debian Bullseye,
which is the operating system we currently use in our Dockerfile.
For consistency, we're using the same version in GitHub Actions.
Note this image requires setting a password. Otherwise we get an error:
> Database is uninitialized and superuser password is not specified.
> You must specify POSTGRES_PASSWORD to a non-empty value for the
> superuser. For example, "-e POSTGRES_PASSWORD=password" on
> "docker run".
Since now we're setting a password in the postgres service, we also need
to provide the `PGPASSWORD` environment variable (or to specify the
password in the `database.yml` file, which we do for GitLab since it
uses a separate database configuration file). Otherwise we get an error:
```
PG::ConnectionBad: connection to server at "::1", port 5432 failed:
fe_sendauth: no password supplied (PG::ConnectionBad)
```
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
