### Context The `release-tools` repository plays a critical role in managing GitLab’s release and auto-deploy tagging processes. Any changes to this repository can potentially impact the stability of these processes, particularly during high-stakes events like security releases. These releases are sensitive and time-critical, and delays caused by unnoticed issues can have serious consequences for the company. Currently, there is no consistent method for validating changes to `release-tools` before they affect live processes, which introduces risk into every merge. A more reliable testing process is needed to ensure that changes do not break critical release workflows. ### Problem Statement Changes in the `release-tools` repository can inadvertently affect the release and auto-deploy tagging processes, particularly for security releases. These issues often go unnoticed until a security release is underway, at which point the process is already under high pressure, and any delays can have significant impacts on the company. Given the complexity and sensitivity of security releases, it’s essential to ensure that any updates to `release-tools` are thoroughly tested before being merged. The current lack of a pre-merge validation process increases the risk of introducing bugs that disrupt the release process at critical moments. ### Goal The goal of this epic is to introduce a **shadow release process** to validate every merge request in the `release-tools` repository. This process will simulate an entire release cycle—major, minor, patch, security, and auto-deploy on disposable clones of the GitLab projects. By doing so, we will: _Ensure that any changes to release-tools do not break or delay any part of the release process, especially security releases._ ### DRI `tbd` ### Participants `tbd` ### Proposed solution - to be re-verified 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. 1. When a pipeline runs, we create a new subgroup and fork all our projects 2. Then in CI we override the projects class to target these disposable clones, 3. 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 #### References * Promoted from https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/831 - see that for original context