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 and major.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