[FF] generated_ref_commits_for_automatic_rebase -- record commit to MR links for automatic rebase merges

Summary

Roll out the feature currently behind the generated_ref_commits_for_automatic_rebase feature flag.

  • DRI: @marc_shaw
  • Team Slack channel: #g_code_review

Note

Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. Feature flag controls · Feature flag lifecycle

What could go wrong?

The flag turns on a database write. When enabled, merging a merge request with automatic rebase before merge writes one p_generated_ref_commits row per commit that lands on the target branch, capped at 500 by the existing limit: 500. Today only merge trains write to that table.

Blast radius is bounded:

  • Only projects with automatic_rebase_enabled and a merge method of ff or rebase_merge are affected. There is no Service Ping metric for automatic_rebase_enabled, so the population cannot be sized in advance, which is why this is behind a flag at all.
  • p_generated_ref_commits is classified table_size: small and is range-partitioned by project_id. For scale, merge_request_diff_commits is over_limit and stores a row per commit per diff version for every merge request, so one row per commit per merged automatic-rebase merge request is small next to it.
  • No new queries are introduced. MergeRequests::OldestPerCommitFinder and MergeRequest.by_related_commit_sha already read the table.

Two known rough edges, tracked separately and worth watching during rollout:

  • Rows are written before the fast-forward, so a merge that fails after the rebase leaves rows behind with no cleanup outside merge trains (#571785).
  • upsert_all provides no deduplication, so repeated merge attempts on the same merge request write repeated rows.

Watch table growth on https://dashboards.gitlab.net alongside the usual merge request throughput panels.

Rollout

Run all production /chatops in #production and cross-post the results to #g_code_review. Background: incremental rollout process, feature actors.

Non-production

/chatops gitlab run feature set generated_ref_commits_for_automatic_rebase 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set generated_ref_commits_for_automatic_rebase true --dev --pre --staging --staging-ref

Production — percentage rollout (wait ≥15 min between steps, watch dashboards):

/chatops gitlab run feature set generated_ref_commits_for_automatic_rebase <percentage> --actors

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss generated_ref_commits_for_automatic_rebase true
/chatops gitlab run feature set --group=gitlab-org,gitlab-com generated_ref_commits_for_automatic_rebase true
/chatops gitlab run feature set --user=marc_shaw generated_ref_commits_for_automatic_rebase true

Before global rollout

Confirm the relevant gotchas before going to 100% — see enabling a feature for GitLab.com:

Cleanup

Remove the flag once deemed stable — see cleaning up. Track it here, or open a follow-up Feature Flag Cleanup issue. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check <merge-request-url> <milestone>
/chatops gitlab run feature delete generated_ref_commits_for_automatic_rebase --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set generated_ref_commits_for_automatic_rebase false                                         # production
/chatops gitlab run feature set generated_ref_commits_for_automatic_rebase false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete generated_ref_commits_for_automatic_rebase --dev --pre --staging --staging-ref --production  # remove entirely