We'd like to enable a merge queue for the opensearch-migrations repository on the main branch.
Why: opensearch-migrations has high PR volume relative to other repos in the project. A merge queue would improve merge velocity by automatically serializing PRs and validating them against the latest base branch + queued changes, without requiring authors to manually rebase and re-run checks.
Requested configuration:
- Enable "Require merge queue" branch protection on
main
- Merge method: merge (not squash, not rebase)
- Status check timeout: 120 minutes -- based on the last 20 merged PRs, our longest-running GitHub Actions check (
eks-integ-test) typically takes 68-97 minutes, with an observed max of 120 minutes
- Build concurrency: default to start
CI migration note: We have 60+ GitHub Actions checks per PR. We understand that each workflow will need merge_group added as a trigger event alongside pull_request for checks to run in the merge queue. We also have Jenkins-triggered checks that will need to be configured to trigger on the gh-readonly-queue/main branch prefix. We'll handle this migration on our side.
Operational concern: In an emergent situation (e.g., a critical production fix needs to land immediately) we need a way to bypass the merge queue. The docs indicate that administrators can "merge without waiting for requirements to be met" to bypass branch protections. Since we don't have admin permissions, we'd be dependent on an admin to force-merge on our behalf. With 60+ checks including EKS integration tests and Jenkins deployment pipelines that routinely take 70-100 minutes, emergent situations where the queue is blocked by external CI issues are a realistic scenario. What is the recommended process and expected turnaround time for requesting an admin-assisted force-merge?
We'd like to enable a merge queue for the
opensearch-migrationsrepository on themainbranch.Why:
opensearch-migrationshas high PR volume relative to other repos in the project. A merge queue would improve merge velocity by automatically serializing PRs and validating them against the latest base branch + queued changes, without requiring authors to manually rebase and re-run checks.Requested configuration:
maineks-integ-test) typically takes 68-97 minutes, with an observed max of 120 minutesCI migration note: We have 60+ GitHub Actions checks per PR. We understand that each workflow will need
merge_groupadded as a trigger event alongsidepull_requestfor checks to run in the merge queue. We also have Jenkins-triggered checks that will need to be configured to trigger on thegh-readonly-queue/mainbranch prefix. We'll handle this migration on our side.Operational concern: In an emergent situation (e.g., a critical production fix needs to land immediately) we need a way to bypass the merge queue. The docs indicate that administrators can "merge without waiting for requirements to be met" to bypass branch protections. Since we don't have admin permissions, we'd be dependent on an admin to force-merge on our behalf. With 60+ checks including EKS integration tests and Jenkins deployment pipelines that routinely take 70-100 minutes, emergent situations where the queue is blocked by external CI issues are a realistic scenario. What is the recommended process and expected turnaround time for requesting an admin-assisted force-merge?