Release Version v4.31.0-gitlab

What's New in this Version

4.31.0 (2025-11-05)

Features

• add index validation for NullBatchingStrategy in background migrations (90c6880)
• datastore: add replica connectivity tracking with quarantine mechanism (e652d0d)
• registry: add database prefer mode (7bfefd8)
• registry: check for invalid lockfiles state on startup (9d8efa1)
• registry: import-command: allow user to determine detail log directory (f7dadb1)

Bug Fixes

• add support for recursive introspection of GCSBucketKeyer interface (e35a438)
• bbm progress metric collection and log field collition (1dcbaf7)
• race condition in TestDBLoadBalancer_ProcessQueryError (78e4646)

Tasks

All tasks must be completed (in order) for the release to be considered workflowproduction.

1. Prepare

1. Set the milestone of this issue to the target GitLab release.
2. 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

1. Trigger the release:prepare job in the release stage on the master branch.
2. 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. 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.
3. Get the release MR approved and merged. The release:tag job detects the updated changelog and creates a new annotated tag.

Documentation/resources

The release documentation can be found here.

3. Update

1. The version bump for CNG is automatically created by the renovate bot, which is triggered every 15-30 minutes.
   1. Check for the renovate MR here. Once the MR is created:
      1. Mark it as related to this release issue.
      2. 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.
2. 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
3. The version bump for Omnibus is automatically created by the renovate bot, which is triggered every 15-30 minutes.
   1. Check for the renovate MR here. Once the MR is created:
      1. Mark it as related to this release issue;
      2. Let the bot pick a Distribution reviewer.
4. The version bump for Charts is automatically created by the renovate bot, which is triggered every 15-30 minutes.
   1. Check for the renovate MR here. Once the MR is created:
      1. Mark it as related to this release issue;
      2. Let the bot pick a Distribution reviewer.
5. 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)])".
   1. Wait for the CNG version bump to be merged.
   2. 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.
   3. 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
      1. Version bump for Pre-Production and Staging.
      2. Version bump for Production Canary.
      3. Version bump for Production Main Stage.
6. 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

1. Add the following instructions to each deployment MR.

   • Version bump for Pre-Production and Staging.
     • Check the #qa-staging Slack channel 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 for errors.
     • Check metrics dashboard.
   • Version bump for Production Canary.
     • Check the #qa-production Slack channel for canary 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 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 for errors.
     • Check metrics dashboard.

2. Let the assignee SRE know about these changes.

4. Complete

1. Assign label workflowverification once all changes have been merged.
2. Assign label workflowproduction once all changes have been deployed.
3. Close this issue.
4. Use Duo to generate a Mean Time to Merge Report with the following prompt and include the output in the issue comments:

Prompt

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.