<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=198270) </details> <!--IssueSummary end--> ## Problem to solve Migration of the [security development from dev.gitlab.org to GitLab.com](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/121), introduced the usage of private projects in a private group to work on security fixes. Currently, the security release process uses the following infrastructure: * 3 repositories * Canonical: `gitlab.com/gitlab-org/gitlab` - Used for regular development * Security: `gitlab.com/gitlab-org/security/gitlab` - Used for security development * Build: `dev.gitlab.org/gitlab/gitlab-ee` - Used for packaging. * Protected branches from Canonical are synced to Security via push mirror * Branches from Security are synced to Build via push mirror. ```mermaid graph LR classDef canonical fill:#74bd3d,stroke:#333,stroke-width:1px classDef security fill:#e086bd,stroke:#333,stroke-width:1px subgraph Canonical c-master(master) c-auto-deploy(12-8-auto-deploy-20200120) c-stable(12-8-stable) c-feature(feature/some-new-feature) end subgraph Security s-master(master) s-auto-deploy(12-8-auto-deploy-20200120) s-stable(12-8-stable) end subgraph Build b-master(master) b-auto-deploy(12-8-auto-deploy-20200120) b-stable(12-8-stable) end c-master -->|push mirror| s-master s-master -->|push mirror| b-master c-stable -->|push mirror| s-stable s-stable -->|push mirror| b-stable c-auto-deploy -->|push mirror | s-auto-deploy s-auto-deploy -->|push mirror | b-auto-deploy class c-master,c-stable,c-auto-deploy canonical class b-master,b-stable,b-auto-deploy canonical class s-master,s-stable,s-auto-deploy security ``` Current mirroring capabilities are limiting us in a few ways: 1. ~~Push mirroring will delete anything in the destination that isn't in the source. This means we can't create the `auto-deploy` branch solely on Security, as Canonical's push mirror will attempt to delete it. If the branch is protected the mirroring will be blocked entirely; if it's unprotected it gets deleted.~~ => :white_check_mark: https://gitlab.com/gitlab-org/gitaly/issues/2452, https://gitlab.com/gitlab-org/gitlab/issues/207416 1. ~~A single branch divergence breaks mirroring for all branches. This means that when we merge a security fix into `12-7-stable-ee` on Security, for example, no other changes *in any branch* from Canonical can be pushed until the divergence is resolved.~~ => :white_check_mark: https://gitlab.com/gitlab-org/gitaly/issues/2451 1. "Only mirror protected branches" creates a tight coupling between protected branches and push mirroring. We can't, for example, protect a branch but not have it be mirrored, or vice-versa. Because of the preceding reasons, when performing a security release, mirroring needs to be disabled between Canonical and Security, which has the consequence of auto-deploys to GitLab.com to be blocked as well until the security release is completed, which can take some days. We need to find a way for auto-deploy branches from Canonical and Security to be free-flowing all the time, so we can: * Merge regular fixes on Canonical and security fixes on Security at will. * ~~Continue the mirroring between these two repositories when specific branches have diverged.~~ :white_check_mark: ## Proposal: Introducing 'branch rules' per mirror With 'branch rules' per mirror, we'll be able to specify which protected branches are mirrored across repositories. The concept is similar to [Protected branch wildcards](https://gitlab.com/help/user/project/protected_branches#wildcard-protected-branches) in a way that it'll allow us to only mirror branches that match the wildcards. With this setup enabled, the expected outcome will be to reconstruct our infrastructure to: * ~~`master` and `stable` branches from Canonical are synced to Security via push mirror~~ :white_check_mark: * `auto-deploy` branches between Canonical and Security are updated through merges * ~~Protected Branches from Security are synced to Build via push mirror.~~ :white_check_mark: ```mermaid graph LR classDef canonical fill:#74bd3d,stroke:#333,stroke-width:1px classDef security fill:#e086bd,stroke:#333,stroke-width:1px subgraph Canonical c-master(master) c-auto-deploy(12-8-auto-deploy-20200120) c-stable(12-8-stable) c-feature(feature/some-new-feature) end subgraph Security s-master(master) s-auto-deploy(12-8-auto-deploy-20200120) s-stable(12-8-stable) end subgraph Build b-master(master) b-auto-deploy(12-8-auto-deploy-20200120) b-stable(12-8-stable) end c-master -->|push mirror| s-master s-master -->|push mirror| b-master c-stable -->|push mirror| s-stable s-stable -->|push mirror| b-stable c-auto-deploy -->|merge | s-auto-deploy s-auto-deploy -->|merge | b-auto-deploy class c-master,c-stable,c-auto-deploy canonical class b-master,b-stable,b-auto-deploy canonical class s-master,s-stable,s-auto-deploy security ``` ### Intended users * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) ### Permissions and Security Follows the same permission scheme of Repository Mirroring section (only available to Maintainers and higher roles) ### Links / references - [Security releases as part of the auto-deploy](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/109)