Mayra Cabrera requested to merge split-publish-step-on-security-release into master Jun 03, 2021

What does this MR do?

Splits publish step on security release template to avoid overloading the package server

Example

Open up for a surprise 🍨

Security patch release: 13.12.3, 13.11.6, 13.10.6

First steps

Disable Omnibus nightly builds by setting the schedules to inactive: https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules.
Ensure that Canonical, Security and Build repositories are synced:
```
# In Slack
/chatops run mirror status
```
Modify the dates below to accurately reflect the plan of action.

Early-merge phase

Up until the 27th, or one day before the Security Release due date

Merge the merge requests targeting default branches

# In Slack
/chatops run release merge --security --default-branch

On the 27th (one day before due date)

If this date is on a weekend, do this work on the next working day.

Notify AppSec Engineers that the Security Release has started. Link to the blog post on security: https://gitlab.com/gitlab-org/security/www-gitlab-com/-/merge_requests/

Merge security merge requests targeting default branches

# In Slack:
/chatops run release merge --security --default-branch

Merge backports and any other merge request pending:
```
# In Slack:
/chatops run release merge --security
```
If any merge requests could not be merged, investigate what needs to be done to resolve the issues. Do not proceed unless it has been determined safe to do so.

On the Due Date

Packaging

Ensure tests are green in CE and green in EE

# In Slack:
/chatops run release status --security

Tag the 13.12.3 security release, and wait for the pipeline to finish: /chatops run release tag --security 13.12.3
Tag the 13.11.6 security release, and wait for the pipeline to finish: /chatops run release tag --security 13.11.6
Tag the 13.10.6 security release, and wait for the pipeline to finish: /chatops run release tag --security 13.10.6

Waiting between pipelines is necessary as they may othewise fail to concurrently push changes to the same project/branch.

Check that EE and CE packages are built:
- 13.12.3: EE packages and CE packages
- 13.11.6: EE packages and CE packages
- 13.10.6: EE packages and CE packages

Deploy

Verify that release.gitlab.net is running the latest patch version
- Check in Slack #announcements channel
- Go to https://release.gitlab.net/help

Release

Final steps

Sync default branches for GitLab, GitLab Foss, Omnibus GitLab and Gitaly, via ChatOps:
```
# In Slack
/chatops run release sync_remotes --security
```
Verify all remotes are synced:
```
# In Slack
/chatops run mirror status
```
If conflicts are found, manual intervention will be needed to sync the repositories.

Close the security implementation issues

# In Slack
/chatops run release close_issues --security

Notify engineers the security release is out (blog post link needs to be replaced with the actual link):

/chatops run notify ":mega: GitLab Security Release: 13.12.3, 13.11.6, 13.10.6 has just been released: <blog post link>! Share this release blog post with your network to ensure broader visibility across our community."

Enable Omnibus nightly builds by setting the schedules to active https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules
Close the old security release tracking issue and create a new one:
```
 # In Slack
 /chatops run release tracking_issue --security
```
Link the new security release tracking issue on the topic of the #releases channel, next to Next Security Release.

Edited Jun 03, 2021 by Mayra Cabrera

Split publish step on security release