Use cleanly versioned docker image tags and git tags for Security Products releases
Problem to solve
We already started to reconsider the versioning of Security Products and the underlying analyzers (see here for SAST and here for its analyzers).
Though, this doesn't prevent us to cleanly tag the repository and build the corresponding docker images:
1.0.0
1.0.1
-
1.0.2
,1.0
,1
2.0.0
-
2.0.1
,2.0
,2
,latest
This implies:
-
major.minor.patch
are immutable images. -
major
andmajor.minor
images are aliases pointing to the latest corresponding patch release. -
latest
is always pointing to the latest stable image
It's also possible to introduce an edge
image tag built from master if necessary and create any Release Candidates as we need too.
Pros:
This makes a lot more sense for a software release process. It's easier to play with the usual Major.Minor.Patch
version numbers instead of the weird Major-Minor-stable
one. It also makes it easier to associate a docker image tag with the corresponding repository state (commit, tag).
Cons: This implies to have a manual step of creating a git tag to trigger the build of a new docker image, instead of having it automatically build on each push to the branch. Though this looks way more predictable to me, so not that much a cons :)
Proposal
Implement release process to have the above mentioned behavior
What does success look like, and how can we measure that?
Have the release process updated and working as expected.
Links / references
https://gitlab.com/gitlab-org/gitlab-ee/issues/7139 https://gitlab.com/gitlab-org/gitlab-ee/issues/6797 https://gitlab.com/gitlab-org/gitlab-ce/issues/52466