Show the ruleset bypass justification on the pull request

[emilras]

🏷️ Discussion Type

Product Feedback

Body

When a user with bypass permissions merges a pull request that doesn’t meet ruleset requirements (for example, a missing approving review), the merge dialog shows an extended description field. In practice, this is where people write why they’re bypassing the rules.

That text becomes the body of the merge commit message. Having it in the merge commit makes sense. The problem is that the merge commit is the only place it ends up:

Pull request timeline: it shows “merged commit into ”, with no sign that rules were bypassed and no justification.
Audit log: the protected_branch.policy_override event records the actor, branch and overridden rule (review_policy_not_satisfied), but not the reason given.
Rule suites REST API: it returns result: bypass and the rule evaluations, but has no field for a reason.

So the justification is separated from the thing it justifies. Anyone looking at the PR later, such as a reviewer, a teammate or an auditor, has no way of seeing that rules were bypassed or why, unless they know to go and find the merge commit.

Request

• Add a timeline event on the PR when it was merged by bypassing rules, showing which rules were bypassed, by whom, and the justification given.
• Include the justification in the protected_branch.policy_override audit log event.
• Expose it in the rule suites API, for example as a bypass_reason field.
• Optionally, let a ruleset require a justification when bypassing.

Why

Many teams need to justify and periodically review exceptions to branch protection for compliance. The PR is the natural record of a change, so the evidence that its review requirements were bypassed, and why, should live there too.

Related: https://github.com/orgs/community/discussions/205777

[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. ⭐