Merging was blocked due to rule violation errors.

[Ghostbird]

🏷️ Discussion Type

Bug

Body

Our company recently started enforcing that PRs MUST have a matching issue in Jira and that it must have the status "In Review", before the PR‌ can be merged. To achieve this, a check was added, and bypass permissions the PR ruleset were removed¹.

However, now we can't merge any PR. Even though all checks pass, and the merge button is available, trying to merge will give a meaningless error.

After clicking Merge pull request

After clicking Confirm merge

The underlying network call returns a HTTP 422 without any more information than that error message:

Merging was blocked due to rule violation errors.

I let GTP-6 Astra bang its metaphorical head against it for a few sessions. Those verified that there's no explanation in the repository ruleset, there are no applicable organisation level rulesets, there are no classic branch protection rules. The single applicable ruleset at repository level seems to be set up correctly. The HTTP response error gives no useful info. In they end the sessions all concluded that it's impossible to diagnose the error, given the information that Github gives us.

One oddity of note: If I give myself bypass rights in the ruleset, the merge does work, without showing a Bypass rules and merge checkbox which normally is required when I'm bypassing something.

Does anyone have an inkling what might cause this?

Footnotes

1. Here's the complete ruleset configuration: ↩

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Ghostbird]

It seems a lot of the changes were a red herring. Just now I found out that I get the same error on a completely different repository in the same organisation, where we do not have these custom checks. It seems it's just the normal ruleset logic that's malfunctioning. I'll investigate some more.

[Ghostbird]

I've done some more checks and concluded:

• It's specifically related to the status checks
• It affects repositories whose status check logic has not changed and has been working for years.
• It seems there's some sort of eventual consistency when saving a rule set. Because toggling things back-and-forth gave inconsistent results.

I heavily suspect it has to do with a Disabled rule set at Organisation level which should not affect anything at all. When I removed it, it didn't solve the problem, but then later when I was trying other things, the problem was suddenly gone, and I couldn't reproduce it.

[Ghostbird]

I encountered the issue again, and I ensured that there were no more organisation level rulesets at all. But after waiting for 15 minutes, nothing changed, and I still can't merge. So that's probably not it either.

[Ghostbird]

Hmm… now I'm not sure. It finally merged after I disabled and reenabled an innocuous CI check requirement that has been in place for years. I'm pretty sure that the real reason is not that, but that this triggers some cache invalidation.

[Ghostbird]

Yeah, it's pretty hard to put a finger on it. Given that all status checks are green, I think it's a real issue exacerbated by a cache invalidation issue. I'm waiting for it to pop-up again and try some more things.

The two hardest things in IT; naming things, and cache invalidation, and off-by-one errors.

[Ghostbird]

Turns out that it's related to checks coming from CircleCI. If those are required and their source is set to something different than Any Source this problem occurs. When you set it to the correct source, the check will pass, you'll see green checkmarks across the board, but you'll be unable to merge.

All the other stuff was apparently just noise during my tests.