This message was deleted.

Currently the best way to get around something like this is to use the "fast forward" feature of our merge queue, which will rebase the whole stack on trunk, ensure "pull_request" actions pass for each branch in the stack in parallel, and then atomically update trunk to point at the top of the rebased stack, so that "push" actions only run once. It depends on exactly how you've configured your CI/CD, I'm referencing GH Action triggers above

I’m using CircleCI which I think will work the same. I will play around with the merge queue, thanks!

Awesome, let us know how it goes 🙂

I posted this in #C02DRNRA9RA, but to close the circle here - it’s hard to know if it worked because the merge queue stopped after the first PR

that's correct — i was mistaken earlier

Are you comfortable giving the Graphite app permission to bypass branch protection rules?

Yes.

Do you care about the PRs within the stack showing the correct diff on GitHub after they have been merged?

I would label that “nice to have”

Do you care that the PR shows “merged” on GitHub (as opposed to “closed”)?

Not really.

If the first few PRs in the stack pass CI, but there is a failure midway through, should they all be removed from the queue, or should the passing PRs be merged?

TL;DR - I want the entire stack to be merged all at once or not at all. I feel like a description of how CI works in my system is in order here. When a commit is pushed to a branch, CI runs some checks like build and test, and they show up as GitHub checks on the PR. When a branch is merged to trunk, it runs those checks plus a more extensive (integration) test suite, and then (if that passes) it deploys to production. So I don’t really know how CI relates to the merge queue. There’s nothing really for each individual PR to “pass” upon merge, other than going through the whole deployment process, which I’m trying to avoid.

Does your CD trigger on each commit to trunk or each push to trunk? I.e., do multiple commits being added to the trunk branch simultaneously trigger multiple CD runs?

Each push to trunk.

So I don’t really know how CI relates to the merge queue. There’s nothing really for each individual PR to “pass” upon merge, other than going through the whole deployment process, which I’m trying to avoid.

the merge queue (currently) runs your individual PR CI again after rebasing to ensure that the checks pass on the version that will actually be merged

Is that specific to GitHub actions? The only way to run my CI checks is by pushing a new commit on the branch. When I ran the merge the only CI jobs I saw were on trunk.

That may have been because your branch didn't need to be rebased — what happens if you queue multiple prs based on a single version of main such that everything other than the first one needs to be rebased as part of the merge?

ah yes that would trigger the CI checks on the branch