Adjust single patch template to follow out-of-band guidelines

What does this MR do and why?

• Adjust single patch template to follow out-of-band guidelines

Patch releases are scheduled twice a month and target the maintained versions. Patches that deviate from this practice are considered out-of-band and are the result of a release exception process https://handbook.gitlab.com/handbook/engineering/releases/#exception-process. This commit updates the single patch template to follow the out-of-band practices.

Test

Open up for a surprise 🤡

Out-of-band Patch Release 18.11.2

Preparation

Note

Out-of-band patches are the result of an approved release exception process

• Link the approved exception request to this issue.
• Ensure required merge requests are merged (this step must be completed before proceeding)

	Request
	<release/task issue url>	<release/task issue url>

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
  • 18-11-stable-ee
• cng-ee
  • 18-11-stable
• gitaly
  • 18-11-stable
• gitlab-pages
  • 18-11-stable
• omnibus-gitlab-ee
  • 18-11-stable
• gitlab_kas
  • 18-11-stable

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 gitlab 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 gitlab run mirror status

• Tag 18.11.2 and confirm the job has finished:

  /chatops gitlab run release tag 18.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.

• Ask the author of the exception request to add an explanation to the blog post describing the reasoning of the out-of-band patch.

• Check the build progress of the Omnibus EE and CE packages. Do not play any manual jobs.

  • CE
  • EE

• Check the build progress of the CNG container images. Do not play any manual jobs.

  • CE
  • EE
  • UBI
  • FIPS

Note

Package builds for Omnibus and CNG can take up to 100 minutes to complete.

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 gitlab run deploy 18.11.2-ee.0 release

• Verify the deployment to release.gitlab.net has successfully completed. A Slack notification will be posted in #announcements.

Release

• Publish the packages via ChatOps:

  /chatops gitlab run publish 18.11.2

• Verify that the chatops publish pipeline created by running the above command succeeded.
• Retry any failed pipelines for 18.11.2. ChatOps job logs: <Paste the chatops publish command CI pipeline URL here for easy access>
• Verify that the trigger job check-packages-availability completed successfully in the Omnibus EE pipeline
• Verify that the trigger job check-packages-availability completed successfully in the Omnibus CE pipeline
• Verify that Docker images appear on hub.docker.com: EE / CE
• Verify that all the jobs in the CNG pipelines completed successfully
  • CE
  • EE
  • UBI
  • FIPS

Final steps

• Update the blog post filename to match the date on which BLOG_POST_MR will be merged
• Merge the blog post.
• Create the 18.11.2 version on version.gitlab.com.
• Transition release blog posts to the docs site. After publishing the patch blog post on https://about.gitlab.com/releases/categories/releases/, notify @sselhorn via the #docs Slack channel that the new patch release blog post is available. Share the URL link.
• Add timestamps and durations on incident.io (located at the bottom right of the incident page), this data feeds the release Incident Dashboard.
• Remove release managers from the exception request assignees.
• Add a comment to the exception request issue to notify the author that the patch release is available (share the blog post URL link), and to request they complete the post-release items (FCL and incident review).

  Note: The following steps can be completed without waiting for the author to finish the FCL and incident review.

• Notify the patch release has been published (blog post link needs to be replaced with the actual link).

  /chatops gitlab run notify ":mega: GitLab Patch Release:  has just been released: <blog post link>! Share this release blog post with your network to ensure broader visibility across our community.
  When is the next Release? Check it on the 'Release Information' dashboard: https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1"

Release Certification

The release certification process may apply to this release. cc @gitlab-com/gl-security/product-security/federal-application-security

Author Check-list

• Has documentation been updated?