we have merge queue/ci optimizations turned on (for bottom and top of stack.. since we are forced to do bottom instead of just top). our users will send many pulls from the stack to the merge queue, but they will run into issues at the middle of the stack that are fixed in the top that aren't getting merged. perfect world we'd want tests run on the top most mergable PR before going to the merge queue but i dont think theres a way to do that right? are there any best practices around this where a stack might be a multiple phased release and people want to push the first phases before being done with the stack? this is somewhat a Continuous delivery thing too that i can see snags on where you might be all done with the stack but need to release in phases, and then run into merge queue failures in the middle of the stack. And we definitely do not want to run tests on every pull in the stack only the merge points.

Hey Kyle! Yea, with CI Optimizations on bottom + top, middle PRs skip CI on purpose. So if the tip has the fix but the middle is still broken, that middle won’t get re-tested until it becomes the new bottom of the stack. For phased releases, you can merge the ready PRs at the bottom with Merge N and keep stacking above this way the whole stack doesn’t need to be done first. Closest merge-time option is Graphite MQ Parallel CI set to run on the topmost PR: *https://graphite.com/docs/stacking-and-ci* · *https://graphite.com/docs/merge-queue-optimizations* Are you on Parallel CI already, or just CI Optimizations?

we have both on, users want to know which stack has the issue and tests to run there instead of throwing it to the merge queue and going back and forth and having to throw it to the merge queue again to tests since the stack is blocked from runnig with the grphite ci optimizser. it seems like a sensible configuration option would be to run on the top stack, and the highest mergable stack. i.e. the first 4 stacked pulls are ready 4 review , ci runs at that one. would be more meaningful than the bottom one for us. or some sort of stack of stacks for these sort of multi phase releases/work efforts, where we can split the draft prs into a separate stack based on the first phase stack.

I’m not aware of a “run CI on the highest mergeable PR” setting today. The optimizer is bottom N (up to 10) + top of stack: *https://graphite.com/docs/stacking-and-ci* Two workarounds that often help: (1) set bottom N to your phase size (e.g. bottom 4 if the first four are the merge point), or (2) put each phase in its own stack so that merge point is the tip and gets CI without enqueueing unfinished upstack. I will log this feature request for the team, no ETA on when we might(or if we might) implement it but if we do have traction we will double back and alert you. Thanks!