Since Bundler 2.4.19, including in Ruby 3.2.3, it's possible to define
the Ruby version in the Gemfile by indicating which file contains the
version [1].
There are at least two practical cases where this is an advantage.
First, people using RVM in development will no longer accidentally run
the application using the wrong Ruby version (which, before these
changes, might happen if they switch to a branch using a different Ruby
version and forget to run `rvm use` or exit the current folder and enter
it again) because they will get an error when trying to do so.
Second, people using services like Heroku no longer need to modify the
Gemfile.
The disadvantage is that, now, every time we update the Ruby version, we
have to remember to run `bundle` so our `Gemfile.lock` gets the new
version.
[1] https://github.com/rubygems/rubygems/releases/tag/bundler-v2.4.19
We had three files that were almost identical, and we can use
environment variables to specify the differences.
Note we're using the `PGUSER` and `PGPASSWORD` variables, since these
variables will automatically be used by the PostgreSQL client when we
have a blank `username` and `password` keys in the `database.yml` file
(which we did until now). The difference between these variables and the
`POSTGRES_USER` and `POSTGRES_PASSWORD` variables is that the `PG`
variables are used by the client connecting to the database, while the
`POSTGRES_` variables are used by the Docker postgresql image when
creating the database superuser.
For consistency with the code in our github workflows (and everywhere
else in the postgres world), we're respecting this double standard. The
fact that there are two different names for what's basically the same
thing makes the code confusing, though, particularly when running the
docker-compose commands, since we get the password from an environment
variable but we have to assign two different environment variables with
it.
So we're accepting both `PGPASSWORD` and `POSTGRES_PASSWORD` variables
in the database configuration file. This way, developers using
docker-compose can use `POSTGRES_PASSWORD` for everything and it'll work
fine. We're also making `PGPASSWORD` default to `POSTGRES_PASSWORD` so
we don't get a warning if we only set `POSTGRES_PASSWORD`:
```
WARN[0000] The "PGPASSWORD" variable is not set. Defaulting to a blank
string.
```
Also note we're using `DB_HOST` instead of `PGHOST` because that's the
variable Rails currently uses by default for new applications [1].
Finally, note we're using `.presence` in the `ENV` calls in the
database.yml file. The `PGPASSWORD` variable was set to an empty string
when running docker-compose, so using `ENV["PGPASSWORD"] ||` wouldn't
work.
[1] https://github.com/rails/rails/blob/c90a8701e5/railties/lib/rails/generators/rails/app/templates/config/databases/postgresql.yml.tt#L22
The alternative text of the image was useless, and we were depending on
an external server in order to display it. Furthermore, the text inside
the image was pretty small.
So we're displaying the output of the command as plain text.
There was a typo where we said we were creating the containers but we
were building the image.
While none of these commands are necessary because they're run
automatically when first running the `db:create` rake task, I think it's
better to show them separately, since the `build` command might be used
to rebuild the image, and running the `create` command separately makes
it easier to know what's going on.
We're also removing the "start database service" step, since it's
automatically started because the app service depends on it.
Finally, we're updating one command for macOS.
Docker and Docker Compose are included in most Linux distributions, and
we don't know whether the windows error we talked about is still
relevant in 2024. In any case, the Docker documentation to install
windows is a better resource for that than our documentation.
We're also using the same Docker commands for every operating system.
Other than checking typos and styling, we're removing references to
"Main URL" (which isn't used since commit f87165851), and updating the
process to configure the map.
So now we install a specific version of Node.js and use the packages
required for Debian Bookworm.
For consistency, we're also making them similar to the Ubuntu
instructions and installing rbenv instead of RVM. Since we now suggest
rbenv in both cases as well as in the macOS instructions, we're also
listing rbenv as the first option in the generic local installation
instructions.
This command simplifies some of the steps. However, there's a gotcha: it
might fail if the database requires username and password and they
haven't been configured before executing it.
We were following it about half of the time and we even added it to our
former `.mdlrc` file. However, for some reason, MDL doesn't detect this
rule when specified in the `.mdlrc` file, so we didn't notice we weren't
following it in many cases.
Now that we're using a style file to configure MDL, we can enable this
rule again and apply it, since now MDL correctly includes it in its
report.
Note that, in order to have some consistency, we're always writing
"Consul Democracy", instead of using capital letters sometimes (but not
always), like we did until now.
This rule is broken when we have ".,;::!?" in the headers.
We have removed the ones with ":" but kept the ones
with "?", so this rule will always warn in these cases.
We were using the SSH URL in the Docker documentation, while using the
HTTPS URL everywhere else. The HTTPS URL is the right one in this case
because it's meant for people who won't have write access to the
repository.
