CI and Docker images for multi-branch projects
Commit 9cf8f45f introduces a flag for disabling pushing of Docker images built in CI on a non-primary branch. This allows work on "feature" branches without overwriting production images in the Docker registry built on the primary branch.
The changed approach creates a new problem: The CI pipeline consists of jobs in multiple stages where later stages depend on the images built and pushed in earlier stages. Images are passed between stages through the Docker registry. When not pushing to the registry, later stages use the image built on the primary branch. Most crucially, this renders test jobs ineffective, because they cannot access the image which is supposed to be tested.
To mitigate this problem, images could always be pushed with a tag corresponding to the commit's SHA-1 hash.
The primary tag is still only pushed on the primary branch.
Modification of Dockerfiles would be required, so that later stages can be configured in CI to use the proper tag when accessing images built in earlier stages.
A set of guidelines is required to prescribe the tag name format and how the commit's hash is passed/processed in the Dockerfile.
For example, images which have multiple "released" tags (e.g. mod-mpmitk-setuid
) require a syntax to concat the tag with the commit's hash.
- released tag:
httpd:latest
- commit hash (this makes it easier to check out the images related to a commit)
- hash only
httpd:latest-c6fc159d0ed79463abbd0644e88fd81fc516139c
- prefixed with
c
httpd:latest-cc6fc159d0ed79463abbd0644e88fd81fc516139c
- prefixed with
c-
httpd:latest-c-c6fc159d0ed79463abbd0644e88fd81fc516139c
- hash only
- GitLab CI pipeline ID (this corresponds more closely to build artifacts and allows creating several pipeline executions which all work independently)
- internal id
httpd:p-64
- id
httpd:p-131592
- internal id
As an extensions, is there a simple way of also publishing tags with the version of the software included in the images?