Release Version v4.33.0-gitlab (#1803) · Issues · GitLab.org / container-registry

Release Version v4.33.0-gitlab

## What's New in this Version  [copy changelog here] ## Tasks All tasks must be completed (in order) for the release to be considered ~"workflow::production". ### 1. Prepare 1. [x] Set the milestone of this issue to the target GitLab release. 1. [ ] Set the due date of this issue to 10 days before the [date of the target GitLab release](https://about.gitlab.com/releases/#upcoming-releases) <details> <summary>Documentation/resources</summary> The due date is set to 10 days before the targeted GitLab release date to create a buffer of 5 days before the merge deadline. See [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline) for more information about the GitLab release timings. </details> ### 2. Release 1. [x] Trigger the `release:prepare` job in the `release` stage on the `master` branch. 1. [x] Review the release MR created during the step above. For each change in the new release, check if the ~"cannot-rollback" or the ~"high-risk-change" label has been applied. If any MR contains the label: 1. [x] Ensure that _no_ code changes that rely on the ~"cannot-rollback" MRs are included in this release. These should be separated into two consecutive releases. 1. [x] Get the release MR approved and merged. The `release:tag` job detects the updated changelog and creates a new annotated tag. <details> <summary>Documentation/resources</summary> The release documentation can be found [here](https://gitlab.com/gitlab-org/container-registry/-/blob/master/CONTRIBUTING.md#releases). </details> ### 3. Update 1. [x] The version bump for [CNG](https://gitlab.com/gitlab-org/build/CNG) is automatically created by the renovate bot, which is triggered every 15-30 minutes. 1. [ ] Check for the renovate MR [here](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests?scope=all&state=opened&label_name[]=automation%3Abot-authored&search=container-registry). Once the MR is created: 1. [x] Mark it as related to this release issue. 1. [ ] Either request a review from `@gitlab-org/maintainers/container-registry` to speed up the process, or just let the bot pick a Distribution reviewer. If reviewing the MR, make sure: - [x] The MR is targeting the `master` branch. - [x] The MR has a green pipeline on GitLab.com. 1. [ ] In case when expedited merging is required, try escalating in one of the following Slack channels: #g_build #g_operate #distribution_maintainers 1. [ ] The version bump for [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests) needs to be done manually ([example](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/4247)) as the CI job is currently not functioning. - [ ] Assign to the reviewer suggested by reviewer roulette 1. [x] The version bump for [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) is automatically created by the renovate bot, which is triggered every 15-30 minutes. 1. [ ] Check for the renovate MR [here](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests?scope=all&state=opened&label_name[]=automation%3Abot-authored&search=container-registry). Once the MR is created: 1. [ ] Mark it as related to this release issue; 1. [ ] Let the bot pick a Distribution reviewer. 1. [ ] In case when expedited merging is required, try escalating in one of the following Slack channels: #g_build #g_operate #distribution_maintainers 1. [x] The version bump for [Charts](https://gitlab.com/gitlab-org/charts/gitlab) is automatically created by the renovate bot, which is triggered every 15-30 minutes. 1. [ ] Check for the renovate MR [here](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests?scope=all&state=opened&label_name[]=automation%3Abot-authored&search=container-registry). Once the MR is created: 1. [ ] Mark it as related to this release issue; 1. [ ] Let the bot pick a Distribution reviewer. 1. [ ] In case when expedited merging is required, try escalating in one of the following Slack channels: #g_build #g_operate #distribution_maintainers 1. [ ] Version bumps in [K8s Workloads](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com) need to be done manually for now as CI is broken. The MR title should be "Bump Container Registry to [version] ([environment(s)])". 1. [x] Wait for the CNG version bump to be merged. 1. [x] Check MRs included in the release for the labels ~high-risk-change, ~cannot-rollback. - [ ] If they exist, add the same label to each deployment stage. - [ ] Follow the [potentially risky deployments](#potentially-risky-deployments) instructions. 1. Each environment needs to be deployed and confirmed working in the order listed below, before merging the next MR. To see the version deployed in each environment, look at the [versions chart in Grafana](https://dashboards.gitlab.net/goto/F44DoeCIg?orgId=1) 1. [ ] Version bump for Pre-Production and Staging. 1. [ ] Version bump for Production Canary. 1. [ ] Version bump for Production Main Stage. 1. [ ] Assign MRs to our stable SRE counterparts in Delivery team: - [ ] Dat Tang \@dat.tang.gitlab - [ ] Jenny Kim \@jennykim-gitlab - if they are not responding try pinging @release-managers on #g_delivery 1. [ ] If this is the final registry release for the milestone, create an MR to update [`REGISTRY_SELF_MANAGED_RELEASE_VERSION`](https://gitlab.com/gitlab-org/container-registry/-/blob/master/.gitlab/ci/migrate.yml?ref_type=heads#L9). Merge this MR after the milestone is complete, and the version has been added to the self-managed release for that milestone. This ensures we can detect breaking changes in registry pre-deploy/post-deploy database migrations between consecutive GitLab releases. You can verify the registry versions for the last GitLab milestone self-managed release by checking [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/18-0-stable/config/software/registry.rb) (update branch to last milestone) and [Charts]( https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/CHANGELOG.md?ref_type=heads), with Charts milestone mappings available in the [documentation](https://docs.gitlab.com/charts/installation/version_mappings/). #### Potentially risky deployments <details> <summary>Instructions</summary> 1. Add the following instructions to each deployment MR. - [ ] Version bump for Pre-Production and Staging. - [ ] Check the [`#qa-staging` Slack channel](https://gitlab.slack.com/archives/CBS3YKMGD) for `staging end-to-end tests passed!`. Make sure the corresponding pipeline started _after_ the registry deployment completed. Otherwise, wait for the next one. - [ ] Check [logs](https://nonprod-log.gitlab.net/goto/f3fbccdb9dea6805ff5bbf1e0144a04e) for errors. - [ ] Check [metrics dashboard](https://dashboards.gitlab.net/d/registry-main/registry-overview?orgId=1&var-PROMETHEUS_DS=Global&var-environment=gstg&var-stage=main). - [ ] Version bump for Production Canary. - [ ] Check the [`#qa-production` Slack channel](https://gitlab.slack.com/archives/CCNNKFP8B) for `canary end-to-end tests passed!`. - [ ] Check [logs](https://log.gprd.gitlab.net/goto/9a66e350-fea0-11ed-a017-0d32180b1390) for errors (`json.stage: cny`). - [ ] Check [metrics dashboard](https://dashboards.gitlab.net/d/registry-main/registry-overview?orgId=1&var-PROMETHEUS_DS=Global&var-environment=gprd&var-stage=cny). - [ ] Version bump for Production Main Stage. - [ ] Check the [`#qa-production` Slack channel](https://gitlab.slack.com/archives/CCNNKFP8B) for `production end-to-end tests passed!`. Make sure the corresponding pipeline started _after_ the registry deployment completed. Otherwise, wait for the next one. - [ ] Check [logs](https://log.gprd.gitlab.net/goto/7dc6f73d5dd4cc4bebcd4af3b767cae4) for errors. - [ ] Check [metrics dashboard](https://dashboards.gitlab.net/d/registry-main/registry-overview?orgId=1&var-PROMETHEUS_DS=Global&var-environment=gprd&var-stage=main). 2. Let the assignee SRE know about these changes. </details> ### 4. Complete 1. [ ] Assign label ~"workflow::verification" once all changes have been merged. 1. [ ] Assign label ~"workflow::production" once all changes have been deployed. 1. [ ] Close this issue. 1. [ ] Use Duo to generate a Mean Time to Merge Report with the following prompt and include the output in the issue comments: <details> <summary>Prompt</summary> ``` Generate a report covering the mean time to production for the commits listed under the "What's New in this Version" section of this issue description, excluding the "build" category. Be sure to include all and only these commits. For each commit, find the linked merge request and use that data where directed. Present results in a single combined summary table with the following: commit short sha, MR title formatted as a link back to the MR, commit category (no emoji), MR authored date, MR merge date, days to merge, days to production. Use this issue's closed date as the date these commits reached production. Use the MR closed date as the merge date. Use the MR authored date as the authored date. Include the date used for the production date before the table. Summarize the overall mean time to merge and to production at the end. Also summarize the number of days the release workflow process extended mean time to production based on the number of days this issue remained open. Only present the data, do not make recommendations. Do not truncate the tool output. ``` </details>

issue