Instead of building all images individually, try and build Apertis-based ones from the same common ground. First create a fairly basic Apertis ospack with a few development tools in, then create a Docker image out of it and layer things on top of it.
This unifies the previously separate overlays for the package builder and the package source builder, only keeping the real differences in their respective overlays.
We opt to not use Docker proper since it requires non-trivial
Docker-in-Docker setup. Makisu, which could be used as an alternative,
unfortunately, has buggy implementation of the ADD command, leaving us
the only option to use Kaniko.
The docker building step is templated in .gitlab-ci.yml to avoid
repetition. The Debian-based images don’t normally have to depend on the
rootfs building step, but to be able to run them asynchronously in the
same pipeline stage we need to declare the dependency anyway, as GitLab CI
does not currently support empty needs lists.
The branches named apertis/* build their respective Apertis releases,
everything else builds the default defined in the CI YAML file.
The jobs for apertis/* branches tag their build images as latest, every
other job uses the branch name.
There is also an alternative (commented out) algorithm for getting the tag: if the branch matches the (removed due to the lack of objections to the current implementation)RELEASE variable (sans apertis/ prefix), it is tagged latest, otherwise the branch name. This would imply a workflow involving patching the RELEASE variable value in the pipeline each time we branch.
For robustness, the debos rootfs step uses a stable v2020 image builder step instead of the currently built one.