Release Version v3.88.0-gitlab
What's New in this Version
3.88.0 (2023-12-19)
✨ Features ✨
- add referrers data to internal List Tags API (fa28ee6)
- datastore: importer: use progressbar to show import progress (3be86b9)
- importer: import command: expose tag concurrency option gcs (8a9fdcd)
⚙ ️ Build ⚙ ️
- deps: update module cloud.google.com/go/storage to v1.36.0 (117dad0)
- deps: update module github.com/data-dog/go-sqlmock to v1.5.1 (d7763ea)
- deps: update module github.com/jackc/pgx/v5 to v5.5.1 (10b8550)
- deps: update module github.com/jszwec/csvutil to v1.9.0 (8e181b1)
- deps: update module github.com/spf13/viper to v1.18.1 (1bc5bca)
- deps: update module github.com/xanzy/go-gitlab to v0.95.1 (2c10193)
- deps: update module github.com/xanzy/go-gitlab to v0.95.2 (7f1d8ec)
- deps: update module google.golang.org/api to v0.153.0 (1a9edc1)
- deps: update module google.golang.org/api to v0.154.0 (bf21ad7)
Tasks
All tasks must be completed (in order) for the release to be considered workflowproduction.
1. Prepare
-
Set the milestone of this issue to the target GitLab release. -
Set the due date of this issue to 10 days before the date of the target GitLab release
Instructions
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 for more information about the GitLab release timings.2. Release
- Read the release documentation.
- Run the
make release-dry-run
command. - Review each MR and check if the cannot-rollback or the high-risk-change label has been applied. If any MR contains the label:
- Ensure that no code changes that rely on the cannot-rollback MRg are included in this release. These should be separated into two consecutive releases.
- Run the
make release
command. - A new tag should have been created and pushed.
3. Update
Note: Version bumps for CNG, Omnibus and GDK can be triggered at the "same" time. Only the Charts and K8s Workloads bumps need to wait for the CNG one. It's highly recommended to trigger both CNG and Omnibus bumps together so that the Distribution team can see them while reviewing.
-
Version bump in CNG is automatically done using the internal release-cli
. An MR should be found open on the CNG MR page after manually triggering theversion-bump:cng
job. If opening this MR manually please give it the title "Bump Container Registry to [version]". -
Review the CNG Version bump MR and make sure all pipelines associated with the MR ran to completion. After reviewing the MR and its pipeline, set the "~workflow::ready for review" label on the MR and request a maintainer review from @gitlab-org/maintainers/container-registry
. For the maintainer review, a maintainer should check the CNG MR to make sure:-
The description contains the change log for the specific release version. -
The MR is targeting the master
branch. -
The MR has a green pipeline on GitLab.com.
-
Once all the above checks have been verified, a maintainer can proceed to merge the MR. If you encounter any issues when merging, request help by following the distribution MR workflow.
-
Version bump in Omnibus is automatically done using the internal release-cli
. An MR should be found open on the Omnibus MR page after manually triggering theversion-bump:omnibus
job. If opening this MR manually please give it the title "Bump Container Registry to [version]". -
Version bump in Charts is automatically done using the internal release-cli
. An MR should be found open on the Charts MR page after manually triggering theversion-bump:charts
job (which requiresversion-bump:cng
to be triggered first). If opening this MR manually please give it the title "Bump Container Registry to [version]". -
Version bumps in K8s Workloads are automatically done using the internal release-cli
. There should be three separate MRs, listed below, on the K8s Workloads MR page after manually triggering theversion-bump:k8s
job (which requiresversion-bump:cng
to be triggered first). Each environment needs to be deployed and confirmed working in the order listed below, before merging the next MR. If opening this MR manually please give it the title "Bump Container Registry to [version] ([environment(s)])".-
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 instructions.
-
-
Version bump for Pre-Production and Staging. -
Version bump for Production Canary. -
Version bump for Production Main Stage.
-
-
Version bump for GDK is automatically done using the internal release-cli
. An MR should be found open on the GDK MR page after manually triggering theversion-bump:gdk
job. If opening this MR manually please give it the title "Bump Container Registry to [version]".-
Assign to the reviewer suggested by reviewer roulette
-
Potentially risky deployments
Instructions
-
Add the following instructions to each deployment MR.
-
Version bump for Pre-Production and Staging. -
Check the #qa-staging
Slack channel forstaging end-to-end tests passed!
. Make sure the corresponding pipeline started after the registry deployment completed. Otherwise, wait for the next one. -
Check logs for errors. -
Check metrics dashboard.
-
-
Version bump for Production Canary. -
Check the #qa-production
Slack channel forcanary end-to-end tests passed!
. -
Check logs for errors ( json.stage: cny
). -
Check metrics dashboard.
-
-
Version bump for Production Main Stage. -
Check the #qa-production
Slack channel forproduction end-to-end tests passed!
. Make sure the corresponding pipeline started after the registry deployment completed. Otherwise, wait for the next one. -
Check logs for errors. -
Check metrics dashboard.
-
-
-
Let the assignee SRE know about these changes.
Release instructions
Instructions
Bump the Container Registry version used in CNG, Omnibus, Charts and K8s Workloads by manually triggering these on the release
job.
The CNG image is the pre-requisite for the remaining version bumps which may be merged independently from each other. Only CNG and K8s Workloads version bumps are required for a GitLab.com deployment. The deployment is then completed as documented here. Charts and Omnibus version bumps are required for self-managed releases.
Please mark parent tasks as completed once the corresponding merge requests are merged.
Version bump merge requests should appear automatically in the Related merge requests
section of this issue.
Note: According to the Distribution Team Merge Request Handling documentation, we should not assign merge requests to an individual.
Merge Request Template
For consistency when updating manually, please use the following template for these merge requests:
Branch Name
bump-container-registry-vX-Y-Z-gitlab
Commit Message
Bump Container Registry to vX.Y.Z-gitlab
Changelog: changed
Title
Bump Container Registry to vX.Y.Z-gitlab
Description
Repeat the version subsection for multiple versions. As an example, to bump to v2.7.7 in a project where the current version is v2.7.5, create an entry for v2.7.6 and v2.7.7.
## vX.Y.Z-gitlab
[Changelog](https://gitlab.com/gitlab-org/container-registry/blob/release/X.Y-gitlab/CHANGELOG.md#vXYZ-gitlab-YYYY-MM-DD)
Related to <!-- link to this release issue -->.
4. Complete
-
Assign label workflowverification once all changes have been merged. -
Assign label workflowproduction once all changes have been deployed. -
Update all related issues, informing that the deploy is complete. -
Close this issue.