Pivot mergify config to use a merge queue #6211
Conversation
In Qiskit#6188 and Qiskit#6117 we changed the mergify configuration to use the smart strict mode which silently maintains a merge queue for us. This option has recently been superseded by building explict merge queues that enable more rich control over how PRs to merge get queue together. [1] This commit switches the mergify config to use an explicit queue for merging to give us more explicit control over how mergify is going to merge PRs for us. This also opens up new options if we were to have a mergify subscription at a future date, primarily speculative testing on the merge queue [2] which will enable better throughput because it validates the potential future state all at once and lets us run testing in parallel. [1] https://docs.mergify.io/actions/queue/ [2] https://docs.mergify.io/actions/queue/#speculative-checks
|
I support finding some way to use merge trains. (Whether using mergify or another tool). |
|
Does this enable having a different set of checks for the ready-to-enter-the-queue check, vs final-merge-to-master check? Keeping a streamlined set of checks for the former but a slower/more complete for the latter would seem a potentially good idea. |
In theory it does as we can now configure the pull request queue conditions to be a subset of jobs and then have the queue rules be the full set. But, in practice because github, CI, and mergify are 3 different, disconnected systems it would be tricky to implement. The first issue comes up with github's branch protection rules. Since we don't force (and actually can't short of removing write permission from the core team) the usage of mergify we need branch protection rules to ensure that we don't accidentally merge something before the required checks pass. But, mergify is bound by the same branch protection rules and won't consider a PR ready for the merge queue until it satisfies the branch protection rules. The only option to do this I guess would be to disable the required status checks in the branch protection rules and enforce by convention using mergify to do all the PR merging. But then there are other things like how to make CI trigger different jobs based on whether it's in the merge queue or not. |
|
One other thing here is github natively supports automerging now: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request Although the feature set looks more limited, it will just automerge a PR when the branch protection rules are satisfied. It doesn't look like it does updating automatically. |
Summary
In #6118 and #6117 we changed the mergify configuration to use the smart
strict mode which silently maintains a merge queue for us. This option
has recently been superseded by building explict merge queues that
enable more rich control over how PRs to merge get queue together. [1]
This commit switches the mergify config to use an explicit queue for
merging to give us more explicit control over how mergify is going to
merge PRs for us. This also opens up new options if we were to have a
mergify subscription at a future date, primarily speculative testing on
the merge queue [2] which will enable better throughput because it
validates the potential future state all at once and lets us run testing
in parallel.
Details and comments
[1] https://docs.mergify.io/actions/queue/
[2] https://docs.mergify.io/actions/queue/#speculative-checks