Keep separate testing images for "master" and "stable"
Currently we test against the different supported environments (Debian / Ubuntu / Conda on Debian) by having separate Docker images, which are stored in the container registry.
There is a manual job that can be triggered to build these images (from the Dockerfiles in
docker/), and which then pushes the images to the registry.
However we do not currently do any kind of versioning of these images. Each time the image-build jobs are run they overwrite whatever images are currently in the registry.
This is not great, as in principle
master need different testing environments. For example,
stable should work with whatever the minimum requirements were at the time the last minor Kwant version was released. We are, however, allowed to update the minimum requirements of
master (e.g. if the supported OS's bumped the package versions in their repos). Currently, for example, we are not actually testing
stable against the minimum requirements as stated in the documentation (in the state the documentation is on `stable).
Fixing this is in principle quite simple, but comes with its own problems.
.gitLab-ci.yml file there are lines like this:
.ubuntu-env: &ubuntu_env image: gitlab.kwant-project.org:5005/kwant/kwant/ubuntu
We would have to modify these lines and stick a
:stable or something on the end, like:
.ubuntu-env: &ubuntu_env image: gitlab.kwant-project.org:5005/kwant/kwant/ubuntu:stable
Simple enough, right?
Except that whenever we merge
master (or vice versa) we would have to ensure that these lines are not taken over (i.e. that we do not have the
:stable images used by
master or vice versa). Git's default merge strategy will, unfortunately, work against us.
In principle only a few people are merging
stable together, and as long as they are aware of this it should "all be good" (and if we mess up it's easy to fix in a new commit), but it still makes me a little uneasy.
It is also not possible (AFAIK) to tell git to apply a particular merge strategy (
ours in this case) to individual files.