Release Version v4.27.0-gitlab
What's New in this Version
4.27.0 (2025-08-28)
Features
- add OpenTofu media types (8465a8d)
- add retry logic for database row count metrics lock acquisition and extension (734faad)
- bbm: add support for backoff and avoid func not found (9d7f100)
- datastore: add database row count metrics with distributed locking (7a7fa66)
- new DLB health check endpoint (42841af)
Bug Fixes
- add retries calculation to all other methods in azure_v2 (c5588eb)
- avoid unknown host and lb recovery on timeouts (a1ebe0f)
- docs: correct typos in dev docs (f540bcc)
- fix passing log fields from context to logger in rate-limiter (1407441)
- properly set TTL when setting urlcache objects in Redis (32b9e10)
- restore _total suffixes for notifications metrics, add _count to retries histogram (f0ae24b)
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
Documentation/resources
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
-
Run the make release-dry-run
command. -
Review each MR in the new release 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.
Documentation/resources
The release documentation can be found here.
3. Update
-
The version bump for CNG is automatically created by the renovate bot, which is triggered every 15-30 minutes. -
Check for the renovate MR here. Once the MR is created: -
Mark it as related to this release issue. -
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:-
The MR is targeting the master
branch. -
The MR has a green pipeline on GitLab.com.
-
-
-
-
The version bump for GDK needs to be done manually (example) as the CI job is currently not functioning. -
Assign to the reviewer suggested by reviewer roulette
-
-
The version bump for Omnibus is automatically created by the renovate bot, which is triggered every 15-30 minutes. -
Check for the renovate MR here. Once the MR is created: -
Mark it as related to this release issue; -
Let the bot pick a Distribution reviewer.
-
-
-
The version bump for Charts is automatically created by the renovate bot, which is triggered every 15-30 minutes. -
Check for the renovate MR here. Once the MR is created: -
Mark it as related to this release issue; -
Let the bot pick a Distribution reviewer.
-
-
-
Version bumps in K8s Workloads need to be done manually for now as CI is broken. The MR title should be "Bump Container Registry to [version] ([environment(s)])". -
Wait for the CNG version bump to be merged. -
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.
-
- 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
-
Version bump for Pre-Production and Staging. -
Version bump for Production Canary. -
Version bump for Production Main Stage.
-
-
-
If this is the final registry release for the milestone, create an MR to update REGISTRY_SELF_MANAGED_RELEASE_VERSION
. 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 (update branch to last milestone) and Charts, with Charts milestone mappings available in the documentation.
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.
4. Complete
-
Assign label workflowverification once all changes have been merged. -
Assign label workflowproduction once all changes have been deployed. - Close this issue.
Edited by Pawel Rozlach