Skip to content

Cleans up PatchRelease::Issue logic

Mayra Cabrera requested to merge remove-ext-maintenance-policy-methods into master

What does this MR do and why?

Patch releases targeting the three versions covered by the maintenance policy and including bug and security fixes will be the default patch release. However there might be patch releases targeting a specific version, this logic resides in the PatchRelease::Issue class.

This commit performs a cleanup on the PatchRelease::Issue class by:

  • Dropping the maintenance policy methods. Those were designed to account patch releases with only bug fixes
  • Adjust the single_version_patch template to only refer to one version

Also this commmit modifies the Task::Release::Issue to always create a patch task for the current version if no version is set.

Related to gitlab-com/gl-infra/delivery#20173 (closed)

Test

Monthly

11:51:21 ❯ TEST=true rake release:prepare\[17.1.0\]
Result

Release 17.1

First steps

First Staging Rollback Practice

Date to be Completed:

Second Staging Rollback Practice

Date to be Completed:

Hot patching production practice

Date to be Completed:

The work here is to be done by the next release managers. Please tag them to the item below.

  • @name
  • Perform hot patching Practice
  • Hot Patching practice is documented: <link to comment>
  • Set Due date for this issue to the date of the next practice session. If none, set it to the release date.

Check Pre environment

Date to be Completed: Friday, Jun 14

Up until Friday, Jun 14

  • Ensure any deploys that do not make it to canary are investigated. Disable canary if necessary.
  • Push any successful deploy to canary into production after some time has passed (preferably 1h).
  • Should any deployment blockers prevent automatic promotions to production, this requires approval by the SRE On-Call.
    1. Ask for permission to promote the release in #production - provide the necessary context to the Engineer
    2. If permission is granted, set the OVERRIDE_PRODUCTION_CHECKS_REASON as a variable in the manual promote job. The value of the variable should be the reason why production checks are being overridden. See gitlab-com-deployer.md#skipping-production-promotion-checks for more info.
    3. This will post a comment into this issue and begin the deployment
    4. Ask the SRE On-Call to respond to the comment with their approval for auditing purposes

Release Preparation

Initial preparation day: Friday, Jun 14

  • Find the latest sha that made it into production successfully: sha
  • 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.
  • Manually create the pipeline to update monthly release status to announced.
  • Notify Engineering Managers and developers that this is the sha that is guaranteed to be released on the 20th: 
    /chatops run notify ":mega: This is the most recent commit running on GitLab.com and this is guaranteed to be released on the 20th.
https://gitlab.com/gitlab-org/security/gitlab/-/commits/<SHA>.
You can check if an MR made the cut by using the following ChatOps command: `/chatops run release check [MR_URL] 17.1`
Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`
  * Documentation about `release check` chatops command: `https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/deploy/auto-deploy.md#status-of-a-merged-mr-with-respect-to-monthly-releases`"
  * Release information dashboard: https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1
  • Verify that the release information dashboard reflects the accurate status "announced" for the active release version (17.1).
    • The updated status can take up to 15 minutes to display on the dashboard once the pipeline to create the metric is finished.

Candidate announcement day: Monday, Jun 17

  • Log latest auto-deploy branch: BRANCH_NAME
  • Ensure this build makes it through into production
  • 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.
  • Grab the sha from this new auto-deploy branch and notify Engineering Managers and developers that this is the candidate sha for the release: 
    /chatops run notify ":mega: This is the _candidate_ commit to be released on the 20th.
https://gitlab.com/gitlab-org/security/gitlab/-/commits/<SHA>
You can check if an MR made the cut by using the following ChatOps command: `/chatops run release check [MR_URL] 17.1`
Further deployments may result in the final commit being different from the candidate. Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`
  * Documentation about `release check` chatops command: `https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/deploy/auto-deploy.md#status-of-a-merged-mr-with-respect-to-monthly-releases`"
  * Release information dashboard: https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1

RC tag day: Tuesday, Jun 18

  • Determine what is the last auto deploy branch to have deployed to production and add it here: BRANCH

  • If you plan to use the latest commit deployed to production for the various components to create the RC, make sure:

  • Create a RC version to ensure that the final version builds correctly

    # In Slack:
/chatops run release tag 17.1.0-rc42

This will use the latest commit deployed to production for the various components that we release. If a different commit is necessary for a component, such as GitLab, you should run the following instead:

/chatops run release tag 17.1.0-rc42 --gitlab-sha=XXX

This will then use XXX as the SHA to create the GitLab stable branches.

NOTE: this SHA is only used if the stable branch has yet to be created. If it already exists, the branch is left as-is.

  • Verify that the CE stable branch contains the right commits

    • There should be at least two commits: the last commit from the previous stable branch (usually a version update), and the sync commit created by the merge train.
    • The sync commit will have the message "Add latest changes from gitlab-org/gitlab@17-1-stable-ee"

  • Verify that the pipelines are green

    # In Slack:
/chatops run release status 17.1.0-rc42

  • Notify Engineering Managers and developers that final candidate has been created:

    /chatops run notify ":mega: The stable branch has been created and the release candidate is tagged. Barring any show-stopping issues, this is the final commit to be released on the 20th.
https://gitlab.com/gitlab-org/security/gitlab/-/commits/17-1-stable-ee
You can check if an MR made the cut by using the following ChatOps command: `/chatops run release check [MR_URL] 17.1`
  * Documentation about `release check` chatops command: `https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/deploy/auto-deploy.md#status-of-a-merged-mr-with-respect-to-monthly-releases`"
  * Release information dashboard: https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1

  • Verify that the release information dashboard reflects the accurate status "RC Tagged" for the active release version (17.1).

    • The updated status can take up to 15 minutes to display on the dashboard once the RC is tagged.

  • Verify that the RC has been deployed to the pre environment

    • Deployment to pre will start automatically. It can take 2 hours to start once the RC is tagged. A notification will be sent to the #announcements channel in Slack when it starts.
    • If required to deploy manually, follow the steps in pre-and-release-environments.md#manual-deployments.

Tag day: Wednesday, Jun 19

Instructions for manual deploy 
    ```sh
    # In Slack:
    /chatops run deploy 17.1.0-ee.0 release
    ```
  • Validate 17.1.0 has been passed automated QA by ensuring the release-gitlab-qa-smoke job from the release deploy pipeline is green.

Past this point, no new code can be added to the release that was not included in the final RC.

Release day: Thursday, Jun 20

Final release is tagged, so any changes will have to initiate a patch release. Reminder: We have a soft PCL today, coordinate with the EOC before deploying to production. Consider not running the post-deploy migration pipeline to keep rollback options available.

  • At 13:00 UTC, post an update about the package building status in #f_upcoming_release 
    :mega: Packages for 17.1.0 are built and will be published at 13:10UTC
  • At 13:10 UTC:
    • ⚠ Make sure that neither packages nor the blog post get published earlier than 13:10UTC without approval by the messaging lead of the release post. Mind that you don't need their approval if you're on time ⚠
    • Publish the packages via ChatOps: 
      # In Slack:
/chatops run publish 17.1.0
    • If anything goes wrong and the release is delayed, ping the release post manager on Slack to make them aware of the issue. Cross-post the slack message to the #marketing channel to notify them too
  • At 14:10 UTC:
    • 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
    • Post an update about the status in #f_upcoming_release 
    :mega: 17.1.0 is published and publicly available

Release Certification

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

/milestone %17.1 /due 2024-04-29

Patch (current version)

11:53:44 ❯ TEST=true rake release:prepare
Result

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:

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.

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.

  • Check the progress of the EE/CE packages:

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

  • 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:  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 2024-04-26 11:54:33.322764 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:33 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fbuild%2FCNG/repository/compare" - 2024-04-26 11:54:33.323077 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/build/CNG, :tag=>"v16.11.1", :branch=>"16-11-stable", :commits=>1} 2024-04-26 11:54:33.600690 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:33 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fbuild%2FCNG/repository/commits/77253742c912caa328d40b6311de838230ccfe17/merge_requests" 2 2024-04-26 11:54:33.600842 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/build/CNG, :version=>"16.11.1", :count=>0} 2024-04-26 11:54:33.906766 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:33 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitaly/repository/compare" - 2024-04-26 11:54:33.906968 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitaly, :tag=>"v16.11.1", :branch=>"16-11-stable", :commits=>1} 2024-04-26 11:54:34.196551 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:34 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitaly/repository/commits/4d27cb3f38284ad1301e3809334d8762f0e73da5/merge_requests" 2 2024-04-26 11:54:34.196672 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitaly, :version=>"16.11.1", :count=>0} 2024-04-26 11:54:34.602799 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:34 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/compare" - 2024-04-26 11:54:34.603513 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitlab, :tag=>"v16.11.1-ee", :branch=>"16-11-stable-ee", :commits=>3} 2024-04-26 11:54:35.269973 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:35 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/commits/602e78c5e61332656afeb2027bb340938b10006d/merge_requests" - 2024-04-26 11:54:35.577595 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:35 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/commits/24e03c9bb04f315c56323c0fdfc25cd0a3868488/merge_requests" 2 2024-04-26 11:54:36.087819 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:36 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/commits/5434fa251336ebaa06fb222de17385c75f1e3460/merge_requests" - 2024-04-26 11:54:36.088174 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitlab, :version=>"16.11.1", :count=>2} 2024-04-26 11:54:36.414701 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:36 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-pages/repository/compare" - 2024-04-26 11:54:36.414902 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitlab-pages, :tag=>"v16.11.1", :branch=>"16-11-stable", :commits=>1} 2024-04-26 11:54:36.907539 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:36 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-pages/repository/commits/da7320e18acf6ad485fe8b6536549fcbfa7d65c5/merge_requests" 2 2024-04-26 11:54:36.907660 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitlab-pages, :version=>"16.11.1", :count=>0} 2024-04-26 11:54:37.255907 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:37 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fomnibus-gitlab/repository/compare" - 2024-04-26 11:54:37.256111 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/omnibus-gitlab, :tag=>"16.11.1+ee.0", :branch=>"16-11-stable", :commits=>1}

title: "GitLab Patch Release: 16.11.2" categories: releases author: ADD_YOUR_FULL_NAME author_gitlab: mayra-cabrera author_twitter: gitlab description: "GitLab releases 16.11.2" tags: patch releases, releases

Today we are releasing versions 16.11.2 for GitLab Community Edition and Enterprise Edition.

These versions resolve a number of regressions and bugs. This patch release does not include any security fixes.

GitLab Community Edition and Enterprise Edition

16.11.2

Important notes on upgrading

This version does not include any new migrations, and for multi-node deployments, should not require any downtime.

Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates.

Updating

To update, check out our update page.

GitLab subscriptions

Access to GitLab Premium and Ultimate features is granted by a paid subscription.

Alternatively, sign up for GitLab.com to use GitLab's own infrastructure.

We’re combining patch and security releases

This improvement in our release process matches the industry standard and will help GitLab users get information about security and bug fixes sooner, read the blog post here.

Draft: Adding 16.11.2 blog post

2024-04-26 11:54:37.640092 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:54:37 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fomnibus-gitlab/repository/commits/e847da7b5f49d3a9804af9902541907b3f035854/merge_requests" 2 2024-04-26 11:54:37.640190 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/omnibus-gitlab, :version=>"16.11.1", :count=>0} Add blog post for 16.11.2 patch release.

Patch issue: test.gitlab.com

Patch (specific version)

11:57:08 ❯ TEST=true rake release:prepare\[16.10.5\]
Results

Release 16.10.5

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:

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.

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.10.5 and confirm the job has finished:

    /chatops run release tag 16.10.5

  • 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.

  • Check the progress of the EE/CE packages:

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.10.5-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 run publish 16.10.5
  • 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:  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.10.5 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 2024-04-26 11:57:04.673203 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:04 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fbuild%2FCNG/repository/compare" - 2024-04-26 11:57:04.673538 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/build/CNG, :tag=>"v16.10.4", :branch=>"16-10-stable", :commits=>1} 2024-04-26 11:57:05.066421 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:05 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fbuild%2FCNG/repository/commits/100c338e40576939e1940d62b872da1ab09b3985/merge_requests" 2 2024-04-26 11:57:05.066591 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/build/CNG, :version=>"16.10.4", :count=>0} 2024-04-26 11:57:05.384616 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:05 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitaly/repository/compare" - 2024-04-26 11:57:05.384806 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitaly, :tag=>"v16.10.4", :branch=>"16-10-stable", :commits=>1} 2024-04-26 11:57:05.798955 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:05 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitaly/repository/commits/9b05e108e38b5f6287d3d8a71b8103076562cfac/merge_requests" 2 2024-04-26 11:57:05.799070 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitaly, :version=>"16.10.4", :count=>0} 2024-04-26 11:57:06.331337 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:06 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/compare" - 2024-04-26 11:57:06.332481 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitlab, :tag=>"v16.10.4-ee", :branch=>"16-10-stable-ee", :commits=>2} 2024-04-26 11:57:06.623680 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:06 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/commits/afe4477d82b04ff967fd90d788883d42f56e9de8/merge_requests" 2 2024-04-26 11:57:07.150623 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:07 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/repository/commits/42668c3dc3305e119374a3befb3cb1bd185ec3f8/merge_requests" - 2024-04-26 11:57:07.150825 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitlab, :version=>"16.10.4", :count=>1} 2024-04-26 11:57:07.657349 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:07 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-pages/repository/compare" - 2024-04-26 11:57:07.657546 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/gitlab-pages, :tag=>"v16.10.4", :branch=>"16-10-stable", :commits=>1} 2024-04-26 11:57:07.964541 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:07 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-pages/repository/commits/7f5c12ab5833e02d51a022b3188984c4b5b89892/merge_requests" 2 2024-04-26 11:57:07.964656 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/gitlab-pages, :version=>"16.10.4", :count=>0} 2024-04-26 11:57:08.359201 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:08 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fomnibus-gitlab/repository/compare" - 2024-04-26 11:57:08.359404 I [dry-run] ReleaseTools::PatchRelease::UnreleasedCommits -- Fetching unreleased commits -- {:project=>gitlab-org/omnibus-gitlab, :tag=>"16.10.4+ee.0", :branch=>"16-10-stable", :commits=>1}

title: "GitLab Patch Release: 16.10.5" categories: releases author: ADD_YOUR_FULL_NAME author_gitlab: mayra-cabrera author_twitter: gitlab description: "GitLab releases 16.10.5" tags: patch releases, releases

Today we are releasing versions 16.10.5 for GitLab Community Edition and Enterprise Edition.

These versions resolve a number of regressions and bugs. This patch release does not include any security fixes.

GitLab Community Edition and Enterprise Edition

16.10.5

Important notes on upgrading

This version does not include any new migrations, and for multi-node deployments, should not require any downtime.

Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates.

Updating

To update, check out our update page.

GitLab subscriptions

Access to GitLab Premium and Ultimate features is granted by a paid subscription.

Alternatively, sign up for GitLab.com to use GitLab's own infrastructure.

We’re combining patch and security releases

This improvement in our release process matches the industry standard and will help GitLab users get information about security and bug fixes sooner, read the blog post here.

Draft: Adding 16.10.5 blog post

2024-04-26 11:57:08.768645 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 11:57:08 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fomnibus-gitlab/repository/commits/2d4adca5971c4ce214dd201fa22403754b1bf270/merge_requests" 2 2024-04-26 11:57:08.768762 I [dry-run] ReleaseTools::PatchRelease::UnreleasedMergeRequests -- Fetched unreleased merge requests -- {:project=>gitlab-org/omnibus-gitlab, :version=>"16.10.4", :count=>0} Add blog post for 16.10.5 patch release.

Patch issue: test.gitlab.com

Patch (three versions, bug and security fixes)

12:00:13 ❯ TEST=true rake security:issue
Results

Patch release: 16.11.2, 16.10.5, 16.9.7

2024-04-26 12:00:33.645748 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline 2024-04-26 12:00:34.077345 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-04-26 12:00:34 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/issues" - 2024-04-26 12:00:34.078319 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline 2024-04-26 12:00:34.916329 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline

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).
  • 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 the slow_jobs stage is not required for the next steps.

  • Check that the CNG Images are built. Do not play any manual jobs.

Deploy

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:

  • Verify that Docker images appear on hub.docker.com: EE / CE

  • Create the versions:

    • Create 16.11.2 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No for the new version.
    • Create 16.10.5 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No for the new version.
    • Create 16.9.7 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No 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:

  • 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.

2024-04-26 12:00:35.329126 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline

Author Check-list

  • Has documentation been updated?
Edited by Mayra Cabrera

Merge request reports