Automatically adjust the configuration of protected branches for a GitLab version
Context
When a new GitLab version is published, the protected branches configuration for GitLab and Omnibus is adjusted to:
- Remove the protection of the previous version.
- Allow maintainers,
gitlab-release-tools-bot
andgitlab-bot
to merge into the new stable branch. - Allow release managers,
gitlab-release-tools-bot
andgitlab-bot
to push
Considerations:
- Rules are adjusted for GitLab and Omnibus canonical projects.
- The branches don't require Code Owner approval and they should not allow to force push.
For example, if we were publishing the 16.3 version, the protected branches rules will be updated to:
- Unprotect
16-2-stable
branch from GitLab and Omnibus - Allow maintainers,
gitlab-release-tools-bot
andgitlab-bot
to merge into the16-3-stable
branch on GitLab and Omnibus. - Allow release managers, the
gitlab-release-tools-bot
and thegitlab-bot
to push into the16-3-stable
branch on GitLab and Omnibus
Proposal
We have two options for how we control the automation for this task.
- Create a new chatops command to allow release managers to trigger on demand.
- Create a new monthly release pipeline and add this as a job.
Either of these options could then interact with a service in a new release-tools that:
- Fetches the active version
- Adjusts the protected branches configuration on GitLab
- Adjusts the protected branches configuration on Omnibus GitLab
- Notifies to Slack if the update was successful or if there were failures.
- In case of failures, a log message should be stated indicating to release managers how to move forward.
Links:
- GitLab API for protected branches https://docs.gitlab.com/ee/api/protected_branches.html
Edited by Amy Phillips