Document the security release process for Managed Versioning
With Pages joining Gitaly in Managed Versioning, but not in Automated version updates, it's time to consolidate our documentation on security releases for components.
Even with the current implementation, the process can be a bit more automated than the one described in our documentation for gitaly.
In order to reduce manual operations for release managers it's important that we follow this procedure:
- We need two implementation issues, one for the component (default branch plus 3 backports) and one for gitlab as
~reduced backport
that only touches the relevant version file - Both issues must be linked to the release issue
- In the early merge phase, the reduced backport for gitlab will ensure we deploy the fix to gitlab.com
- In the backport merging phase, all the components MRs will be merged ensuring that the fix will be included in the next tagged release
There a little complication in this process that is making sure we do not rollback the component as well as not breaking mirroring ahed of time.
Let's consider the following example: this is the repository of a given component, the squared commit represent the SHA that is stored in gitlab-org/gitlab
repository as COMPONENT_NAME_VERSION
file.
gitGraph
commit
commit type: HIGHLIGHT
branch feature-a
branch security-mr
checkout feature-a
commit
checkout main
merge feature-a tag: "gprd + feat a"
branch feature-b
checkout security-mr
commit tag: "gprd + sec fix"
checkout main
merge security-mr tag: "gprd + feat a + sec fix"
checkout feature-b
commit
checkout main
merge feature-b
In a situation like this, we cannot rely on merge commits as they are not ready ahead of time, we don't even want to merge any of the master targeting merge requests or this will breake mirroring.
We can utilize the gprd + sec fix
SHA in our merge request for gitlab-org/gitlab
so that the early merge phase will take care of deploying that commit regardless of when it will be merged.
There is an extra benefit of this approach, in case in the meantime the content of the version file changes on gitlab-org/gitlab
, the merge request will fail due to merge conflict.
To resolve this conflict, avoiding any rollback, it is necessary that we follow this process:
- take the
COMPONENT_NAME_VERSION
fromgitlab-org/gitlab
master (MASTER_COMPONENT_SHA
) - rebase the component merge request so that its branch (security-mr in the above example) starts exactly from
MASTER_COMPONENT_SHA
- rebase this
gitlab-org/security/gitlab
MR onto master updating the version with the new HEAD of merge request on step 2
notes
The merge request for the component must use the same (or very similar) template as the ones for gitlab-org/security/gitlab
.
Status 2023-01-27
- The process is now documented - gitlab-org/release/docs!546 (merged)
- GitLab Pages now has a DangerBot rule to verify that security merge requests starts from the right SHA - gitlab-org/gitlab-pages!847 (diffs)