Vim 8.0 was released in 2016, which should be sufficient backwards
compatibility. We still support 7.4, but will not run it in the CI going
forwards too keep the test matrix sane.
There's no 2.5.x branch any more. Change the default to master, i.e. the
latest release, now that the branch actually reflects the release and
no longer includes patches accidentally merged to the wrong branch.
Keep v2.5.1 around just for safety as it probably is the most widely
used release around.
Would be nice if the 2.6.0 branch was named dev or devel and wasn't
about to disappear as soon as 2.6.0 is released... :-/
Python 3.5 is EOL since Sep 2020.
Python 3.9 is out since Oct 2020.
taskwarrior 2.5.2 is out since Dec 2020 (released only on GitHub though).
It's a bit stupid to have to update it manually, but until we figure it
out something better...
This is simpler and more reliable/predictable:
"git ls-remote 'heads/'" doesn't return anything, while "grep 'heads/'"
returns all branches, so a taskwarrior push causes most docker images
(those that don't have any TASK_VERSION and fallback to the Dockerfile
default) to be rebuilt, not just the one that needs to be.
For the development branches of taskwarrior, caching 2.5.2 or 2.6.0 is
not sufficient since HEAD is still moving.
Build the tag hash based on the HEAD hash of the development branch in
question.
The previous refactor traded build step caching for smaller image size,
which in turn made fast caching of built images possible, and allowed us
to speed up CI builds. But almost any change in Dockerfile required full
rebuild of everything (vim & taskwarrior), so changes to the Dockerfile
became more painful.
This commit refactors the Dockerfile to use multi-stage builds, which
brings build caching back: vim & taskwarrior are built in separate
stages, which are cached step by step, and then the build artifacts are
copied into the main tests image and runtime dependencies are installed.
There's a catch, of course: --cache-from doesn't work with multi-stage
images unless the experimental BuildKit backend and its inline cache
export are enabled. This requires docker 19.03, which shouldn't be hard
to obtain but isn't installed by default on Travis CI.
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.
