I'm trying to implement merge queue for my reposi...
# how-do-i
j
I'm trying to implement merge queue for my repository but my setup is very flaky. Right now I have a PR thats #1 in the queue, but CI has never ran on the most recent commit, so its blocking the queue. How is this supposed to be handled? I have some github actions to try to kick off the CI runs when graphite does a rebase, but it doesn't work 100% of the time.
I have "Fast forward merge" enabled I do not have "CI Settings" enabled
From what I understand the
gtmq_
prefix only shows up if "CI Settings" is enabled, but this has a nasty side effect of marking all PRs as CLOSED instead of MERGED. Which is not an acceptable compromise
c
With Fast-forward on and CI Settings off, Graphite rebases onto trunk and waits for GitHub checks on that new SHA and it won’t open
gtmq_
draft/validation PRs. It relies on Actions firing from the rebase push, which is often flaky. What I suggest is to turn on CI Settings (Graphite needs BPR bypass) so Parallel CI runs on draft PRs: *https://graphite.com/docs/merge-queue-optimizations#how-running-ci-in-parallel-works*. Can you drop the stuck PR URL?
j
turning on CI settings, this ends up marking PRs as closed correct? (even when they merge)
from docs
When an enqueued PR merges, it will be marked as closed in GitHub instead of merged.
we just can't live with this
c
Yep! You’re right. With CI Settings on, GitHub closes the originals (Graphite still treats them as merged). There’s no GA way to keep GitHub-merged with that on. Stay on FF-only if merged state is required. If Linear is in the mix, commit-linking or
externally-merged
before close can help: *https://graphite.com/docs/merge-queue-optimizations*
j
So is there any extra hook/workflow/event to listen on when a PR is picked for the merge queue or something? Somehow I end up in a state where CI is "passing" so it gets placed in the merge queue, but some rebase/push occurs that invalidates that CI run on that commit and i'm stuck in limbo
c
The queue event webhook is something we are investigating but no ETA to relay at this time and I will add you to the feature request. Two hooks that do exist: Graphite comments on the PR when it's enqueued (
issue_comment
trigger), and the queue's rebase fires a normal
pull_request: synchronize
. https://graphite.com/docs/setup-recommended-ci-settings
j
Did you reach any good solution? 😓 Today my Linear issues get stuck in review, linked to a closed PR 🙈
j
If the question is to me, yes, I've had a solid merge queue for awhile now. Couldn't tell you what claude did though..
But, we are using Merge Queue (it marks PRs as closed, but we've managed). I have one required CI check setup in Github called
PR Gate
PR Gate
automatically gets set to sucess based on some github actions if the branch doesn't have a gtmq_ prefix. (So graphite says its ready to merge) But another workflow triggers a set of tests on branches with
gtmq_
prefix, which upon all success, eventually marks
PR Gate
as success.
I don't know what Linear is