Rename patch release templates
What does this MR do and why?
Rename patch release templates
With patch releases being repurposed to releases that include bug and security fixes. This commit:
- Replaces the 'security release' term with 'patch release' on the templates
- Renames the templates used when performing single patch releases vs default patch releases (targeting 3 versions)
Related to gitlab-com/gl-infra/delivery#20049 (closed)
Test
Patch release (default)
Click to expand
Patch release: 16.11.2, 16.10.5, 16.9.7
First steps
-
Start the security_release_prepare:start
job in the security pipeline: https://example.com/foo/bar/-/pipelines/1-
Ensure the security_release:prepare
stage completes before continuing to the next section.
-
-
Modify the dates below to accurately reflect the plan of action. For example, if the planned due date is 28th, update the section titled "One day before due date" to "On 27th (One day before due date)".
Two days before due date
-
Check if the security tracking issue contains any linked issues for projects under GitLab managed versioning that are not automatically processed (cng-ee, gitaly, gitlab-pages). -
If there are any linked issues, follow the release manager instructions and adjust this issue to include any additional steps needed. -
If a Gitaly security fix is included in the upcoming patch release, follow the How to deal with Gitaly security fixes guide.
-
-
Before running the default merge chatops command, disable the security-target issue processor
pipeline schedule to ensure no other issues are linked to the security tracking issue and no linked issues are inadvertently unlinked after this point. -
Check the issues linked to the security tracking issue. If there are any that DO NOT have the security-target label applied, check to make sure they are expected to be included, otherwise unlink them and point the assignees to the correct process. -
Merge the merge requests targeting default branches # In Slack /chatops run release merge --security --default-branch
-
Verify that the table of issues in the security tracking issue has been updated showing the default MRs have been merged or set to Merge When Pipeline Succeeds (MWPS/auto-merge).
One day before the due date
If this date is on a weekend, do this work on the next working day.
-
Start the security_release_release_preparation:start
job of the security pipeline: https://example.com/foo/bar/-/pipelines/1 -
Check that all MRs merged into the default branch have been deployed to production: # In Slack: /chatops run auto_deploy security_status
NOTE: This only checks
gitlab-org/security/gitlab
. If other projects have security MRs you should verify those manually. -
Make sure to execute the post-deploy migration pipeline to ensure that all post-deploy migrations have been executed: /chatops run post_deploy_migrations execute
-
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. -
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
-
If all the security issues have been deployed to production, consider tagging.
On the Due Date
Packaging
-
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
For the next task: Waiting between pipelines is necessary as they may otherwise fail to concurrently push changes to the same project/branch.
-
Tag the 16.11.2 patch release, and wait for the pipeline to finish: /chatops run release tag --security 16.11.2
-
Tag the 16.10.5 patch release, and wait for the pipeline to finish: /chatops run release tag --security 16.10.5
-
Tag the 16.9.7 patch release, and wait for the pipeline to finish: /chatops run release tag --security 16.9.7
-
Check that EE and CE packages are built. Please note the completion of the RAT-Tag
job on theslow_jobs
stage is not required for the next steps.- 16.11.2: EE packages and CE packages
- 16.10.5: EE packages and CE packages
- 16.9.7: EE packages and CE packages
-
Check that the CNG Images are built. Do not play any manual jobs. - 16.11.2: CNG builds
- 16.10.5: CNG builds
- 16.9.7: CNG builds
Deploy
-
Verify that release.gitlab.net is running the latest patch version - Check in Slack
#announcements
channel - Go to https://release.gitlab.net/help
- Check in Slack
Release
Consider communicating with the AppSec counterpart before publishing to sync on the time of releasing the blog post. Emails to the security mailing list are normally handled as a follow up task and should not delay release tasks
-
Publish 16.11.2 via ChatOps: /chatops run publish --security 16.11.2
-
Publish 16.10.5 via ChatOps: /chatops run publish --security 16.10.5
-
Publish 16.9.7 via ChatOps: /chatops run publish --security 16.9.7
-
Verify with AppSec release managers if the blog post is ready to be published. Do not proceed until AppSec has given green light -
Start the security_release_publish:start
stage of the security pipeline: https://example.com/foo/bar/-/pipelines/1 -
Verify that the check-packages
job completes:-
EE check-packages
on 16.11.2+ee.0 -
CE check-packages
on 16.11.2+ce.0 -
EE check-packages
on 16.10.5+ee.0 -
CE check-packages
on 16.10.5+ce.0 -
EE check-packages
on 16.9.7+ee.0 -
CE check-packages
on 16.9.7+ce.0
-
-
Create the versions: -
Create 16.11.2
version on version.gitlab.com. Be sure to mark it as a security release. From theSecurity Release
dropdown chooseNon Critical
. After it is created, theVulnerability Type
column should indicateNo
for the new version. -
Create 16.10.5
version on version.gitlab.com. Be sure to mark it as a security release. From theSecurity Release
dropdown chooseNon Critical
. After it is created, theVulnerability Type
column should indicateNo
for the new version. -
Create 16.9.7
version on version.gitlab.com. Be sure to mark it as a security release. From theSecurity Release
dropdown chooseNon Critical
. After it is created, theVulnerability Type
column should indicateNo
for the new version.
-
Final steps
-
Start the security_release_finalize:start
job in the security pipeline: https://example.com/foo/bar/-/pipelines/1 -
Sync the GitLab default branch by using the merge-train project: -
Disable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Trigger the gitlab-org/security/gitlab@master -> gitlab-org/gitlab@master
pipeline schedule on the merge-train and wait until it finishes. This pipeline will attempt to sync the GitLab default branch. -
If the sync fails, repeat the above step.
-
-
If after 5 times the sync by the merge train continues to fail, use the previous strategy to sync the GitLab project: -
Disable the merge_train_to_canonical
feature flag on ops. -
Enable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Execute the sync_remotes
task on Slack:/chatops run release sync_remotes --security
. In this case, if the sync fails, a merge request will be created and release manager intervention will be required.
-
-
Verify all remotes are synced: # In Slack /chatops run mirror status
If conflicts are found, manual intervention will be needed to sync the repositories.
Patch release for single version
Click to expand
Release 16.11.2
Preparation
Stable branches for GitLab Managed Versioning projects are required to have a green pipeline to perform a patch release. For each of the following branches verify the pipeline is green:
- GitLab
- cng-ee
- gitaly
- gitlab-pages
- omnibus-gitlab-ee
If a failure is found the resolution process differs between each project:
- For GitLab project failures, follow the broken stable branch process.
- For GitLab components, contact the maintainers and notify them about the failure.
-
Ensure that any post-deploy migrations in the stable branch have been executed on GitLab.com by executing the post-deploy migration pipeline: /chatops run post_deploy_migrations execute
.
Packaging
-
Check if mirroring synced stable branches to dev. If the output is ✅ for every repo, we can proceed to tag. Note. If GitLab Canonical to Security mirroring has diverged on the default branch due to security merges this mirror is expected to show as a broken and can be safely ignored./chatops run mirror status
-
Tag 16.11.2
and confirm the job has finished:/chatops run release tag 16.11.2
-
While waiting for packages to build, review and complete the blog post. => BLOG_POST_MR - If the blog post failed to generate, it can be generated manually from the release-tools project with
rake release:patch_release_blog_post
.
- If the blog post failed to generate, it can be generated manually from the release-tools project with
-
Check the progress of the EE/CE packages: -
EE: 16.11.2+ee.0 -
CE: 16.11.2+ce.0
-
Note this may take a while (around 80 minutes).
Deploy
- For patch releases, the only available environment for deploys is
release.gitlab.net
. All GitLab Inc. team members can login to that installation using their email address (through google oauth). - Deployment to release.gitlab.net will only be performed for the current release version. If a previous version is being released, you can move to the next section and begin publishing.
release.gitlab.net
- Deployments to release.gitlab.net are performed automatically.
Instructions to manually deploy if required.
If you need to manually run a deployment, you can do so as follows:
/chatops run deploy 16.11.2-ee.0 release
-
Verify the deployment to release.gitlab.net has successfully completed. A slack notification will be posted in #announcements
.
Release
16.11.2
-
Publish the packages via ChatOps: /chatops run publish 16.11.2
-
Verify that the chatops publish
pipeline created by running the above command succeeded. -
Verify the check-packages
job completes successfully on the EE Pipeline -
Verify the check-packages
job completes successfully on the CE Pipeline -
Verify that Docker images appear on hub.docker.com
: EE / CE
Final steps
-
Merge the blog post. -
Notify the patch release has been published ( blog post link
needs to be replaced with the actual link)./chatops run notify ":mega: GitLab Patch Release: 16.11.2 has just been released: <blog post link>! Share this release blog post with your network to ensure broader visibility across our community."
-
Create the 16.11.2
version on version.gitlab.com.
Release Certification
The release certification process may apply to this release. cc @gitlab-com/gl-security/product-security/federal-application-security
/due in 7 days
Author Check-list
- [-] Has documentation been updated?