For individual analyzers, the reviewer who merges the Merge Request is responsible for creating the relevant tag, per our versioning and release process. In the event that they are unwilling or unable, they should request another reviewer with merge access release on their behalf.
Our release process is aided by scripts stored in our release scripts project.
GitLab Security Products use an independent versioning system from GitLab's MAJOR.MINOR. All products use a variation of Semantic Versioning. DAST has a dedicated versioning process, as documented in the DAST project
Each Security Product releases a new
MAJOR tag with each update to our underlying tools.
For each security product, a tagged image also corresponds to the
git tag of the released version; i.e.
In most circumstances it is preferred to rely on the
MAJOR image instead,
which is automatically kept up to date with the latest advisories or patches to our tools.
Our included CI templates pin to major version but if preferred, users can override their version directly.
Per our Continuous Deployment flow, for new components that do not have a counterpart in the GitLab Rails application, the component can be released at any time. Until the components are integrated with the existing application, iteration should not be blocked by our standard release cycle and process
A Release Manager is assigned to each release and is responsible for:
Release Managers ensure that the latest versions of all projects are published and perform Q&A on the latest release of GitLab.
This should be done on the 18th of each month. Though, this is a soft deadline and there is no harm in doing it within a few days after.
First, create an new issue for a release with a script from this repo:
This issue will guide you through the whole release process. In general, you have to perform the following tasks:
Check that CI job definitions are still accurate in vendored CI/CD templates and all of the ENV vars are propagated to the Docker containers upon
docker run per tool.
If needed, go to the pipeline corresponding to the last git tag, and trigger the manual job that controls the build of this image.