Will merge queue running CI on the top of the stack interfere with

optimize_ci

only running CI on the bottom of the stack?

(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state

I see, thanks! And what benefit exactly do I get from the merge queue if CI already finished on the PR before it’s approved? It seems like now I’m just double-running CI on every PR. Am I missing something?

the CI re-running in the queue is currently expected behavior, even in cases where the PR's CI is green and trunk is unchanged at merge time. It's on the team's radar to detect and handle situations such as these where re-running CI would be redundant. In general though the behavior's intention is to solve for issues organizations with many teams making many merges simultaneously face where trunk frequently breaks, or PRs each pass CI independently but conflict when both land.

It seems like now I’m just double-running CI on every PR. Am I missing something?

Merge queue CI will run on the exact state that will result if the merge goes through, whereas CI on your PR has no such guarantee (because other stuff may have merged since CI ran on the PR).

One thing that is a little annoying about this at the same time is that the merge queue closes the old PR and then creates a temporary PR that it auto-merges. As we link PRs to JIRA tickets (our company does JIRA, but logically, most companies have some sort of "this PR is in the spirit of this product initiative"), this really messes with PR tracking (I'm running into the same issues as @Tyler Laprade above, but wanted to chime in on another issue we're seeing)

yeah that's a known trade-off with using parallel CI. Linear can detect the

externally-merged

GitHub label and use that to correctly make issues

Done

when merge is complete. Not sure if Jira has an equivalent.

Just curious, couldn’t the same end result be achieved by force-merging the actual PRs in quick succession, rather than the draft PR?