Merge queue with Stacked pull requests is creating unnecessary CI runs

[Darian-Morrison]

My team is really enjoying Stacked PRs for slicing large AI-generated changes into more digestible bits of code, but its interaction with the Merge Queue is suboptimal for how we are using the Merge Queue. We are looking for either more configuration options for how Stacked PRs enter the Merge Queue or advice on how we can adjust our CI/CD pipeline to improve throughput of the Merge Queue to work around the current limitations.

Problem

Currently, when you merge a stack via the "Enqueue stack" button - each PR is added to the Merge Queue individually. The Merge Queue then runs CI (on: merge_groupActions) on each individual PR, when in our case, running it on just the top-most PR in the stack (Since it includes the changes for all the stacks) would be sufficient.

Result

The current setup leads to slower-than-necessary Merge Queue throughput and increased opportunity for PRs to be removed from the queue due to flakes or intermittent GitHub Actions issues.

Example

1. "Enqueue stack" (enqueueing the top 3 PRs of a 6 PR stack here)

2. 3 PRs enter the merge queue separately

3. Each PR runs Actions individually, and then I believe they all land on main together.

Suggested Solution

1. Allow for a "Enqueue as Unit"/"Enqueue only base" option

OR

2. Additional Merge Queue settings for "Enqueue only the base of a Stacked PR stack"

CI Context

CI pipeline

We use GitHub Actions to run static checks (type checks, linters and code beautifier validation), Unit/Integration tests) on: pull_request. We then run the above checks on: merge_groupas well as Docker image builds, tagging and deployments to AWS ECS in our development environment. Once merge groups land on main, we trigger a promotion flow to deploy the images to our staging environment and then run some E2E tests. From there, we have an Action that runs on a cron schedule for nightly production deploys, and we can also trigger manual production deploys.

In our case, with Stacked PRs, even running static checks on more than just the top-most PR in a stack is redundant, but the unnecessary Builds + Deploys really hurt our deployment throughput and encourage us to revert back to just shipping Huge PRs or using a traditional PR stack (pre-Stacked PRs we would just change PR origin such that PR1 targets main, PR2 -> PR1, etc and merge PR2 through X into PR1 and then merge PR1 into main), which has its own problems (messy git history, many manual orchestration steps).

Merge queue settings