Hey all, my team has experienced several PRs getting stuck in "merging" state on Graphite since at least Friday. From GitHub's PR page, the mergeability check is showing

Graphite / mergeability_check  Expected — Waiting for status to be reported

. We've had to manually merge several PRs from GitHub (requires bypassing CI checks). Any ideas?

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

could this be caused by devs mixing

git

and

gt

commands when the commit and push branches? there aren't any obvious error messages indicating graphite is out of sync with git, but it is a definite possibility that those having trouble are not consistently using graphite CLI

Hey Dan, tough to say exactly without a specific PR or 2 to look at. Could you share a repo name and PR number? It does seem like based on the limited error messages that this may have to do with rulesets blocking merge that graphite isnt aware of. Do you use rulesets and branch protections rules?

Hi Brett, I'm on Dan's team. The repo is a private repo. Please let me know if there's anything else I can provide that may help.

the things im looking for are repo name (visibility status doesnt matter) and pr number so i can track this down in my logs.

sure, repo name is meld, PR number is 11 this has since been merged manually in Github but experienced the issue prior to that

thanks will see what i can track down in my logs!

thank you!

Good Morning Stephanie, for PR 11, I am seeing the same thing as the comments left by graphite - that is, my logs show

PR BLOCKED with passing CI

meaning graphites understanding of mergability is saying we can merge it but github is telling us otherwise. below screenshots are my logs showing all CI passing and the PR approved and the SHA for ref. This is almost always (as noted in the comment) because of rulesets which we cannot read (ie our "understanding of mergability" i mentioned earlier is purely from classic branch protection rules (BPR)). Are you guys using rulesets? If so, could you share what the look like? Maybe there is an org level ruleset? which seem to be popping up more and more now

hey I can chime in here: here's our repo's current ruleset

thank you! can you share the additional settings of require status checks to pass? ie do you have

Require branches to be up to date before merging

on and or specific checks as required i can check against?

ah, yep sorry missed the collapsed settings

okay some new findings here: the 3 times i see this PR failed to merge the method was SQUASH. This makes sense it could fail given the

Require branches to be up to date before merging

rule. the fourth (and time it worked) it was MERGE. Interesting because

Require linear history

usually blocks merge commits, so you’d expect MERGE to fail and SQUASH to succeed. Very odd but i do see a number of commits post the initial attempt so not out of the question you could have updated it before the successful. What i think would be the best path forward would be is to convert this ruleset into a classic branch protection rule which will give us much more visibility into whats happening should it continue to be a problem, it will also properly block the merge button if its not actually mergable which should prevent this kind of confusion.