Improve release-tools reliability with shadow releases
Problem
Changes in release-tools
may affect the release and auto_deploy tagging process.
It's not uncommon that we merge something that brakes a security release process, but we don't notice it until we perform a security release.
A security release is a stressful process, where a delay can have a serious impact on the company.
It will be desirable to run a shadow release process on every merge-request in release-tools in order to ensure the reliability of our tooling.
Proposed solution
We can run a QA system in CI, generating shadow releases in disposable clones of our projects.
The overall idea is that we can create a subgroup for https://gitlab.com/gitlab-org/release
that holds such releases.
- When a pipeline runs, we create a new subgroup and fork all our projects
- Then in CI we override the projects class to target these disposable clones,
- Finally, we run a set of releases tasks
- tagging a major release
- tagging a minor release
- tagging a patch release
- tagging a security release
- tagging an auto-deploy build
Edited by Alessio Caiazza