Is there a way to differentiate ci workflows running for something in the merge queue vs something something from a standard re-stacking run? Ideally we'd like to run actual merge queue actions on separate infrastructure (a fast lane) than the standard action runs or restacks which could back up the merge queue runs for continuous delivery off the merge queue.

Hey Kyle! You can indeed split these. MQ speculative CI shows up as draft PRs titled

[Graphite MQ] Draft PR

and branches prefixed

gtmq_

: https://graphite.com/docs/merge-queue-optimizations. Normal restack runs use

graphite-base/*

bases (safe to ignore in heavy workflows), and CI Optimizations can skip mid-stack CI outside the queue. Thanks!

thanks for the info! if we disable fast forward merges, will this gtmq_ prefix branch still get created for the queue for us to trigger off of or does it use the actual branch?

Turning off fast-forward merge also disables Parallel CI, so you won't get the

gtmq_

draft branches /

[Graphite MQ] Draft PR

runs those create. With FF off, MQ CI runs on each PR's actual head branch instead.

k thanks just wanted to verify there. and that

gtmq_

branch is really the only way to easily/cleanly tell if something is being run as part of the merge queue's release vs standard CI run?

Yep! With Parallel CI on,

gtmq_

branches are the cleanest hook for push-triggered workflows. You can also branch on draft PRs whose title starts with

[Graphite MQ] Draft PR

(handy for

pull_request

triggers). If FF/Parallel CI is off, Graphite won’t create

gtmq_

branches. MQ CI runs on the normal PR head, so branch-based routing won’t distinguish MQ from restack. https://graphite.com/docs/merge-queue-optimizations