Pin the minor version of Security Products in the vendored includes
Problem to solve
Updating every instances in the world at once each time we release a new version of our Security Products is risky.
While this gives us more flexibility to push updates it also could cause huge troubles because with time it's really hard to ensure every pieces will keep working seamlessly together.
This is also particularly true as we currently don't have a process to publish release candidates.
The current process implies to release a new
x-y-stable docker image tag every month when there is a new version of GitLab.
x-y-stable images are actually acting as a compatibility matrix layer.
When we release a new version of a tool:
- we publish a new semantic version with a git tag:
- we publish a corresponding docker image:
- we override the corresponding major docker image:
- we override the existing
x-y-stableimages that are (supposed to be) compatible with that major version:
And when there is a new monthly release of GitLab we update the CI config to add a new job to publish a corresponding
4 is to me the main issue and the behavior we need to change.
With the vendoring of our job definitions it will be possible to avoid publishing these
x-y-stable images by using directly the semantic version of our tools in the job definition.
As the definition is now included in GitLab itself, there is no more need for that compatibility layer of
Then, to address the issue of having all instances in the world pulling instantly the latest version of our tool, we could pin the
minor version instead of the
Here is an example of how it would end up:
- We publish sast
1.4.0, which also creates a
11.8still uses sast
sast:1.3docker image has not changed.
- We update the vendored include to use
sast:1.4and when GitLab
11.9is released, it uses sast
If we have a bug to fix:
- We publish sast
1.3.1, which also override the
11.8immediately get the patched version
This is a common behavior when dealing with dependencies: pin a minor to get all patches automatically but not the new features.
I think it make sense to ask our users to update to the latest version of GitLab to benefit from new features and it reduces the risk of breaking things as time goes. At the pace of changes happening on the product this seems to be a safer approach.
This will also make it simpler for all stakeholders:
- release process and CI configuration will be simpler
- each version of GitLab has a specific version of the Security Tools explicitly listed in the vendored template (no need to look for matching of
x-y-stablewith the version of the tool.
- newcomers won't have to deal with this unusual versioning and spend time figuring out how it works.
- update vendored templates
update CI config for SAST, DS, CS, DAST and LM to build the
major.minordocker image tag along with
update docs to deprecate the usage of
x-y-stabledocker images, saying that using the vendored template should maintain the correct version automatically. Explain how to override if necessary, but warn that we do not support odd configs.
What does success look like, and how can we measure that?
We only publish docker images matching semantic versions of our tools.