[FF] retain_auto_merge_with_automatic_rebase -- keep auto-merge when automatic rebase handles the target branch
Summary
Roll out the feature currently behind the retain_auto_merge_with_automatic_rebase feature flag.
- DRI: @marc_shaw
- Team Slack channel:
#g_code_review
Introduced by !248017 (merged) (community contribution from @mika.fischer).
When a project uses Fast-forward merge or Merge commit with semi-linear history, a push to the target branch aborts any pending auto-merge on the merge requests targeting it. That assumes the author now has a manual rebase to do. With Enable automatic rebase prior to merge turned on, the rebase happens as part of the merge, so the assumption does not hold. Mergeability::CheckRebaseStatusService already exempts these projects; RefreshService#abort_ff_merge_requests_with_auto_merges did not. The flag gates the new exemption.
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?
Blast radius is narrow: the flag actor is the project, and the code path is only reached for projects that have both ff_merge_must_be_possible? and automatic_rebase_enabled turned on. Everything else keeps the current abort behaviour.
What to watch while it is on:
- Auto-merges that should have been aborted now survive. The exemption is intended to be exactly co-extensive with
MergeStrategies::FromSourceBranch#use_create_ref_service?(automatic_rebase_enabled? && ff_merge_must_be_possible? && should_be_rebased?). If those two ever drift, an auto-merge could be retained on a merge request the merge cannot actually rebase. Watch for a rise in failed auto-merges /MergeRequests::MergeServiceerrors on affected projects. - A retained auto-merge can merge a rebased result no pipeline has tested. Automatic rebase before merge does not re-run CI/CD, which is inherent to the existing feature rather than new here, but this change makes it happen more often because auto-merge is no longer cancelled when the target branch moves. This is the main behavioural consequence and the reason for the flag.
- Merge trains are expected to be unaffected -- the loop already skips anything other than
merge_when_checks_pass, and EE'sshould_be_rebased?returns false for train strategies. Worth confirming no change in merge train abort rates. - Authors on affected projects should stop receiving
aborted the automatic merge because target branch was updatedsystem notes and the accompanying to-do.
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 retain_auto_merge_with_automatic_rebase 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set retain_auto_merge_with_automatic_rebase true --dev --pre --staging --staging-refProduction -- percentage rollout (wait ≥15 min between steps, watch dashboards):
/chatops gitlab run feature set retain_auto_merge_with_automatic_rebase <percentage> --actorsOr target specific actors instead:
/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss retain_auto_merge_with_automatic_rebase true
/chatops gitlab run feature set --group=gitlab-org,gitlab-com retain_auto_merge_with_automatic_rebase true
/chatops gitlab run feature set --user=marc_shaw retain_auto_merge_with_automatic_rebase trueBefore global rollout
Confirm the relevant gotchas before going to 100% -- see enabling a feature for GitLab.com:
- Docs + version history updated -- done in !248017 (merged) (
doc/user/project/merge_requests/auto_merge.md) - Breaking changes announced, if any
- Change management issue opened, if required
- External API consumers handled with a fail-open mechanism, if applicable
Cleanup
Remove the flag once deemed stable -- see cleaning up. The changelog entry was deliberately left off !248017 (merged) because the change ships default-off, so it belongs on the flag-removal MR.
/chatops gitlab run release check <merge-request-url> <milestone>
/chatops gitlab run feature delete retain_auto_merge_with_automatic_rebase --dev --pre --staging --staging-ref --productionRollback
/chatops gitlab run feature set retain_auto_merge_with_automatic_rebase false # production
/chatops gitlab run feature set retain_auto_merge_with_automatic_rebase false --dev --pre --staging --staging-ref # non-production
/chatops gitlab run feature delete retain_auto_merge_with_automatic_rebase --dev --pre --staging --staging-ref --production # remove entirely