## Summary This issue is to roll out the fix for [RFH !3850](https://gitlab.com/gitlab-com/request-for-help/-/work_items/3850) on production, that is currently behind the \`trigger_auto_merge_after_pipeline_creation\` feature flag. Introduced in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/236738. ## Owners - Most appropriate Slack channel to reach out to: \`#g_code-review\` - Best individual to reach out to: @marc_shaw ## Expectations ### What are we expecting to happen? When an MR is created with auto-merge enabled (typically via the \`git push -o merge_request.auto_merge=true\` push option) and the project's \`workflow:rules\` suppress pipeline creation, the MR should auto-merge as soon as \`MergeRequests::CreatePipelineWorker\` finishes, without anyone needing to visit the MR page. Before this flag is enabled, the customer-visible symptom is that scripted MRs pile up open and only merge once a human visits each one in the browser (see [RFH !3850 note 3339062115](https://gitlab.com/gitlab-com/request-for-help/-/work_items/3850#note_3339062115)). ### What can go wrong and how would we detect it? - **Spurious auto-merges**: the new code path only enqueues \`AutoMergeProcessWorker\` when \`diff_head_pipeline\` is nil *and* \`auto_merge_enabled?\` is true. \`AutoMergeService.process\` re-checks \`mergeable?\` before merging, so any MR not actually mergeable is a no-op. - **Worker volume**: every \`CreatePipelineWorker\` invocation now performs one extra \`auto_merge_enabled?\` check; only MRs with auto-merge actually enqueue. Risk of meaningful traffic increase is low. Watch the \`AutoMergeProcessWorker\` queue. - Relevant dashboards: [Sidekiq: auto_merge queue](https://dashboards.gitlab.net/d/sidekiq-queue-detail) ## Rollout Steps Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command. ### Rollout on non-production environments - Verify the MR with the feature flag is merged to \`master\` and has been deployed to non-production environments with \`/chatops gitlab run auto_deploy status <merge-commit-of-your-feature>\` - [ ] Enable the feature globally on non-production environments with \`/chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation true --dev --pre --staging --staging-ref\` - [ ] Verify that the feature works as expected on staging by pushing a no-pipeline auto-merge MR. ### Specific rollout on production For visibility, all \`/chatops\` commands that target production must be executed in the [\`#production\` Slack channel](https://gitlab.slack.com/archives/C101F3796) and cross-posted (with the command results) to the responsible team's Slack channel. - Ensure that the feature MRs have been deployed to both production and canary with \`/chatops gitlab run auto_deploy status <merge-commit-of-your-feature>\` - [ ] Enable for \`gitlab-org\` first: \`/chatops gitlab run feature set --group=gitlab-org trigger_auto_merge_after_pipeline_creation true\` - [ ] Verify against the reproducer project (\`gitlab-org/secure/vulnerability-research/advisories/nvd-mirror-json-data-v2\`) that new scripted MRs auto-merge without manual intervention. ### Preparation before global rollout - [ ] Set a milestone on this rollout issue. - [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. ### Global rollout on production - [ ] Incrementally roll out: \`/chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation 25 --actors\` \`/chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation 50 --actors\` \`/chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation 100 --actors\` Between every step wait for at least 15 minutes and monitor. - [ ] After the feature has been 100% enabled, wait for at least one day before releasing the feature. ### Release the feature - [ ] Create a merge request to remove the \`trigger_auto_merge_after_pipeline_creation\` feature flag. - [ ] Once the cleanup MR has been deployed to production, clean up the feature flag from all environments by running this chatops command in \`#production\` channel: \`/chatops gitlab run feature delete trigger_auto_merge_after_pipeline_creation --dev --pre --staging --staging-ref --production\` - [ ] Close this rollout issue. ## Rollback Steps - [ ] This feature can be disabled on production by running the following Chatops command: \`\`\` /chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation false \`\`\` - [ ] Disable the feature flag on non-production environments: \`\`\` /chatops gitlab run feature set trigger_auto_merge_after_pipeline_creation false --dev --pre --staging --staging-ref \`\`\` - [ ] Delete feature flag from all environments: \`\`\` /chatops gitlab run feature delete trigger_auto_merge_after_pipeline_creation --dev --pre --staging --staging-ref --production \`\`\`