Primary motivation for this is speed: GitHub Actions doesn't limit the
number of concurrent jobs to 4, and also provides a docker registry
(GitHub Packages) that we can use to cache the image (building the image
takes cca 5 minutes, fetching it would take less than 10 seconds). This
is done in another commit.
The workflow definition is a bit more complicated because coveralls
support for GitHub Actions is less mature than for Travis CI, so we need
to manually tell coveralls that all parallel builds have finished and
that it can publish the combined result.
This makes it easier to understand the interaction between the outer and
inner make, as one doesn't need to dig through docker-compose.yml and
possibly Dockerfile to find what command will be run.
It does break the ability to run `docker-compose run --rm tests` but
that's a good thing I believe: I only ever use that when I need a shell
in the container for debugging purposes.
This is a preparation for adding additional commands to the test, like
postprocessing the coverage data, which needs to be processed in the
container (unless we somehow copy the data out of it; but then, we
already install coverage and coveralls inside it, so...).
Additionally, this makes it a bit easier to run the tests locally, which
is helpful when investigating errors. Just a tiny bit, though: it still
requires setting up a fake home with a reasonably minimal .vim and a
python environment with vimrunner.
We're mounting taskwiki read-only (because the docker container runs as
root) so place the pytest cache elsewhere. This means re-running failed
test isn't possible now. If that is desired, we may run the container as
current user (may require libnss-unknown) instead, later.
