So I’ve been getting up to speed on the Mastodon codebase. Here are some notes on getting to green tests locally.
Aside: I generally prefer, in order:
- Improve a project so it needs less documentation to get up-and-contributing.
- Improve a project’s documentation.
- Create external documentation.
I am working on (1).
I am also working (2), but the Mastodon docs repo has (as of this writing) 107 open PRs dating back six months, and the most recent accepted PR was three weeks ago. Dozens of PRs have been added to the queue since then. I appreciate that managing documentation contributions is its own job, but I’m not sure Mastodon is being well-served by their current policy. If any Mastodon core team members read this: I volunteer to help.
At any rate, that brings us to (3), so here we are.
I can’t speak for the Vagrant config; I prefer containers.
Let’s say that by using either the devcontainer config, the Vagrant config, or the documentation, you’ve gotten as far as cloning Mastodon into a Debian or Ubuntu [virtual] machine with all the OS package dependencies installed. Let’s say you’ve also successfully installed Postgres or connected your box to an external Postgres node.
You will need to install the RubyGem dependencies. You may run into problems if you don’t explicitly specify gem groups:
bundle install --path vendor/bundle --with='development test'
You will need to [re]create, migrate your scheme, and seed your database:
RAILS_ENV=test ./bin/rails db:setup
You will also need to precompile web assets for test. It is not enough to precompile them for development. Development mode precompiles assets in
./public/packs; test mode precompiles them into
./public/packs-test. Tests will fail if you do not precompile assets for test, and they will fail with misleading webmock errors.
RAILS_ENV=test NODE_ENV=tests ./bin/rails assets:precompile
Note that the pluralization of the
NODE_ENV is very important. Ask me how long it took me to dial this particular command in.
Do not have ElasticSearch available while running the tests. Some tests will detect that ES is running, try to use it, and fail. If you are using docker-compose, make sure to take down ElasticSearch container before running the suite. (I am trying to get a PR accepted that will ensure the relevant tests never try to use a real ES server).
If you can get this far, you have a fighting chance of running the whole Ruby spec suite without error!