GitHub Community
Repository Rules GA Feedback #61107
Replies: 56 comments 160 replies
-
|
For the use case of exempting bots, how do I exempt commits using the default GitHub Actions token from a workflow? |
Beta Was this translation helpful? Give feedback.
-
|
At the moment, there is not support in Repository Rules for bypassing based on Actions due to the nature of the permission and how they can be triggered. |
Beta Was this translation helpful? Give feedback.
-
|
@patrick-knight I am using a Github App token to do the push action, but it's still showing up in the Repo Rules audit log as |
Beta Was this translation helpful? Give feedback.
-
|
Hey @vibro, Two things, are the insights correct when using "normal" git commands. And can you also opt to try this update to your workflow: |
Beta Was this translation helpful? Give feedback.
-
|
ok |
Beta Was this translation helpful? Give feedback.
-
|
Noted |
Beta Was this translation helpful? Give feedback.
-
|
Looks like when comparing to Branch Protection, it is currently missing the |
Beta Was this translation helpful? Give feedback.
-
|
Those options are available when you select "Require a pull request before merging".
|
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to have access control rules for each repo? For example, each repo should not have more than 10 users with admin permission |
Beta Was this translation helpful? Give feedback.
-
|
This experience is focused on branch and tag protections. |
Beta Was this translation helpful? Give feedback.
-
|
What happened to the standard "branch protection" that was available in the menu previously and the related API (aka does the branch protection API work the same or creates a rule in the background - /repos/(owner)/(repo)/branches/(branch)/protection ). This seems to be the feature for newly created repositories and it creates some UI inconsistencies people get confused about. Will any migration from the "branch protection" settings into a "branch protection rule" happen or is it up to the repo owners to manage the transition by themselves? We're using the enterprise cloud subscription and have automation in scripts that seems is broken so we're doing a root cause investigation and noticed the Changelog + Blog Post and missing UI settings, but no detailed info anywhere. Anyone having the same issue? |
Beta Was this translation helpful? Give feedback.
-
|
@jankudev The new repository rules work along side the existing branch protections, so no existing functionality has been removed.
Currently the transition will be manual as there is a not a full 1:1 migration path and but we are exploring opportunities to assist with the migration in the future. It is possible that branch protections we're disabled via "the danger zone" and can be reenabled there as well: |
Beta Was this translation helpful? Give feedback.
-
|
I've found a use case where the PR checks are not working I get 422 error
|
Beta Was this translation helpful? Give feedback.
-
|
Once you finish selecting the checks hit the ➕ sign to finalize and save the ruleset. |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible to introduce rules around how PRs are merged via these rulesets? For example, using a ruleset to enforce across multiple repositories that PRs must be merged via a squash and merge strategy. As far as I can tell this setting is still only available at the repository level which means we have to configure it in all relevant repos individually rather than applying it on a ruleset that applies to a specific list of repos. It is currently possible to restrict to either rebase merge or squash merge via requiring linear history, but for repos defining infrastructure as code we prefer squash and merge and to disable rebase merge so that commit messages all refer back to their relevant pull request when commit messages are sent to audit logs of deployments elsewhere. Other than that the new feature is amazing, I was worried I’d have to start diving into managing repos via terraform which is a layer of complexity I’m happy to avoid. This in combination with template repos is very powerful. |
Beta Was this translation helpful? Give feedback.
-
This is on our |
Beta Was this translation helpful? Give feedback.
-
|
Question on rule behavior, I created a rule that has "Repository admin" in the bypass list and the option "Restrict updates" enabled. Pull Requests are blocked, even though I am a repository admin, is this expected?
Is this supposed to be the same as the branch protection rule "Restrict who can push to matching branches"? |
Beta Was this translation helpful? Give feedback.
-
@patrick-knight No, the Triage role does not work here because that applies to the entire repo. In contrast, Branch Protections & Rules apply to certain branches. We want people to have Write permissions in general, but not for certain branches (e.g.
We want 2 approvers (any devs on the team), but the team lead is the only one we want to allow to merge to that particular branch. If we just rely on 2 approvers to block merging, we could reach the minimum and then a dev could merge, without the lead to be involved. Again, the Branch Protections "Restrict who can push to matching branches" allowed this behavior, but Rules does not. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, just to add another use case to this thread:
$ gh api /repos/$ORG/$REPO_WITH_BRANCH_PROTECTION/pulls/1234 --jq .mergeable_state
clean
$ gh api /repos/$ORG/$REPO_WITH_RULESET/pulls/5678 --jq .mergeable_state
blocked
I Thanks! Edit: I just noticed this thread from September is about the same issue and includes an acknowledgement from @patrick-knight. |
Beta Was this translation helpful? Give feedback.
-
|
I'm testing out repository rulesets for the first time to reduce our branch protections and I'm running into the same issue mentioned above where the ruleset setup of using |
Beta Was this translation helpful? Give feedback.
-
|
+1 really need a way to express the Any updates here? |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this? It's 2025 and this still seems to be an issue. I have a repo of which I am an admin. I created one ruleset that has two rules:
When I create a PR against the branch that has the rule, I get I don't want to check the bypass rules checkbox as that would also bypass the status checks |
Beta Was this translation helpful? Give feedback.
-
|
Repository rule violations found * Cannot create ref due to create name restrictions. * Branch name must start with a matching pattern: ^feature/\d+-(.*)$. Actually (this what is popping when i try to create branch with matching pattern also). Iam setting rulesets in GitHub, even after setting up branch naming convention regex pattern in metadeta restriction. how should give branch name to create the given regex pattern. help me create branch name patterns, what should i give it and what and all i should enable in rulesets to work the pattern creation. You can have a look at the screenshot below. Kindly do help me out with this. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mohitnvs2397, The rules selected are behaving as defined. As selecting restrict creations blocks the creations of new branches. As far as the rule around branch naming patterns, there seem to be different configurations in the screenshot vs the text post so it's hard to say there. Is the goal to ensure all branches start with |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking to enforce approvals for PRs. 1 approval org-wide. However, we have repositories that have already configured 2 approvals. Will it be overwritten? Will we still be able to configure higher approvals for specific branches? |
Beta Was this translation helpful? Give feedback.
-
|
Rule from the org layer on-top of existing rulesets or branch protections. Effectively you get the most restrictive outcome. If at the org you only define 1 PR approval but at some reposts that is two or three, the repository levels wins. However, the repo would be allowed to have less than 1 approval since that is the org defined minimum. Hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
Can we get the opposite of an exemption list, like an application list? For instance, I want some checks to apply ONLY to certain groups of people... |
Beta Was this translation helpful? Give feedback.
-
|
We're not planning on that, but I am curious to learn more about this scenario when checks are required for only a small group. |
Beta Was this translation helpful? Give feedback.
-
|
Our immediate scenario is that some outside contributors (internal to our company) just aren't up for the rigor of, say, resolving all conversations or abiding by strict static analysis. But our core contributors would still like those requirements, and we can manage outsiders by reviews instead. |
Beta Was this translation helpful? Give feedback.
-
|
We just tried to enable Is there a way for us to have this setting, but only for commits not in the main branch? Or some other similar requirement. If not, would you consider it for the roadmap in a future iteration? |
Beta Was this translation helpful? Give feedback.
-
|
@patrick-knight can you look at this? we are also facing the same. |
Beta Was this translation helpful? Give feedback.
-
|
bump @patrick-knight |
Beta Was this translation helpful? Give feedback.
-
|
Hey y'all thanks for sharing feedback here. This post has gotten pretty big so on occasions I miss some replies and threads 😬 At the moment we don't have any plans for supporting this outside of bypassing the rule. |
Beta Was this translation helpful? Give feedback.
-
|
Seems like this rule is kind of broken currently... The first time anyone bypasses the rule, it seems that every other commit after that also needs to be bypassed. We're migrating all our repos to a monorepo, and we want to enforce linear history for regular day-to-day work. But would like to create a merge commit using I assumed the rule was only enforced for newly added commits, not the entire branch history going back to the beginning of time. |
Beta Was this translation helpful? Give feedback.
-
|
What is the state of the merge queue support? Is this something on the near term roadmap or a technical challenge which will require quite some time to implement? |
Beta Was this translation helpful? Give feedback.
-
|
The upcoming release will allow you to create a merge queue configuration inside rulesets inclusive of bypass. Today you'd need to a repo admin or have the custom role to bypass rules to skip the merge queue defined in the old branch protection rules. We're wrapping up a few last minute changes and should be out in a public beta pretty soon here. Sneak peek:
|
Beta Was this translation helpful? Give feedback.
-
|
looks good, by when would we be able to see this on enterprise cloud? |
Beta Was this translation helpful? Give feedback.
-
|
@patrick-knight any update here? |
Beta Was this translation helpful? Give feedback.
-
|
We're aiming for mid-next week. There were a few things to wrap up on rule insights for queued PRs that took a bit longer than planned. |
Beta Was this translation helpful? Give feedback.
-
|
This is now in public beta! |
Beta Was this translation helpful? Give feedback.
-
|
I am not able to add Edit: I checked via the developer option, and it gives a
|
Beta Was this translation helpful? Give feedback.
-
|
@patrick-knight Okay thanks, but it is super confusing. I think should be parallel what we used to use in |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback we're planing future enhancements here to make that clearer. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kaankoken How did you manage to type and select a rule (status check) on the "Required status check to pass before merging" field ? Would you have any direction based on your experience ? |
Beta Was this translation helpful? Give feedback.
-
|
@lsantosthoughtworks Org checks will only display apps that are installed at the organization level. These apps must be installed with the |
Beta Was this translation helpful? Give feedback.
-
|
Following up to share this ➕ has been removed and a new interface is rolling out.
|
Beta Was this translation helpful? Give feedback.
-
|
Can someone help me with to bypass branch projection rules? I have already checked a post but did not worked out. Edit: I am trying to apply for my personal pro account What I done is:
Still I could not bypass it |
Beta Was this translation helpful? Give feedback.
-
|
😬 Sorry I missed replying here. If you use a team/role does the bypass work as expected? If so it might be additional configuration/permissions on the app. |
Beta Was this translation helpful? Give feedback.
-
|
are there any plans to make org-wide rulesets available with a github team plan? i'm the only member of my organization. i don't want to be forced into an enterprise plan, especially with required workflows moving to repository rules. |
Beta Was this translation helpful? Give feedback.
-
|
Not at the moment. We are investigating bringing an actions workflow rule to repo rulesets. |
Beta Was this translation helpful? Give feedback.
-
|
would that allow team plan users to define org-wide required workflows? |
Beta Was this translation helpful? Give feedback.
-
|
That would allow for requiring workflows per repo. |
Beta Was this translation helpful? Give feedback.
-
|
We're trying to move a number of our repos from branch protection rules to rulesets, but it's causing confusion when people go to If rulesets is supposed to replace branch protection rules, I'd expect some kind of messaging like "You don't have any branch protection rules in place, but you do have rulesets set up. See them here..." (Apologies if this was already mentioned somewhere above, I didn't find it through quick searching.) |
Beta Was this translation helpful? Give feedback.
-
|
In the danger zone of repos there is the ability for admins to disable branch protection rules.
And all the "you haven't protected any of your branches" messages should only apply if there are no rulesets and the create flow also prompts you to use rulesets now as well if you are on the branch protection page. We have not officially replaced branch protections but are obviously heavily implying it right now. That will change over time as we encourage the transition in new ways over time. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok that's good to know, we can look at disabling branch protection rules for repos we've moved over.
This isn't happening for me, unless I'm misunderstanding. I still see the message above even if the repo has rulesets setup and enabled, and if I press that "Add branch protection rule" button it takes me to the regular create page and doesn't mention rulesets. |
Beta Was this translation helpful? Give feedback.
-
Same for me. It's very confusing. I'd suggest to either fix that check (to also consider rulesets) or get rid of the message. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, after adding rulesets that apply to the default branch and are enabled, I'm still seeing the "You haven't protected any of your branches" message under "branch protection". |
Beta Was this translation helpful? Give feedback.
-
|
I've tried using the default branch setting, as well as explicitly setting the default branch name and still get the same result: the confusing "You haven't protected any of your branches". I appreciate rulesets may one day replace branch protection rules, but it's obviously confusing a lot of people. I've seen it enough and know the rulesets apply, but I admit I still find it concerning at first glance and makes me question whether everything is set up correctly. |
Beta Was this translation helpful? Give feedback.
-
|
I've got this scenario that I'm scratching my head over
As the org owner I'm able to successfully create a new repo from the template. Rule insights indicate that a bypass has been applied against the required workflow. My devs are unable to create a new repo from the template and we see the following in the rule insights I've tried creating a role, with a small number of devs, and adding the role to the bypass list of the failing rule. The devs within that role are still unable to create a new repo from the template. This feels like something that should be possible, but I'm not seeing anything else that I'm missing. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to be able to add custom activity types that trigger ruleset workflows. The current behaviour is not sufficient for my use case.
I have a workflow that checks if auto-merge is enabled and if the auto-merge commit message follows the conventional commits specification. |
Beta Was this translation helpful? Give feedback.
-
|
If this comment is to be believed, a previous beta version of the rulesets feature allowed only certain actors to bypass approval requirements on PRs while still requiring them to make a PR in the first place, by breaking things down into two rulesets: one that requires PRs (no bypasses) and one that requires PRs to have approvals (bypasses configured for relevant actors). This is exactly what we want, in order to allow apps to land automated PRs without review, while still requiring normal developers to get approvals. But I am unable to make this work today by granting myself bypass (via both a team I'm in and a repository role that I have). The second ruleset (with the approval rules + bypasses) does not allow bypassing required approvals. I am always faced with this message: Disabling the second ruleset outright permits merging, which indicates that the rules in each ruleset are themselves correct. But of course disabling the second ruleset is equivalent to allowing everyone to bypass this requirement, which is not what we want. (This repository does involve a merge queue (required in the first ruleset) but I temporarily disabled that specific rule and nothing about the situation changed, so this problem seems unrelated to merge queues.) @patrick-knight do you know if this regression is intended or not? |
Beta Was this translation helpful? Give feedback.
-
|
This sounds exactly like the issue I've been having with the feature. I've reported it to GitHub Support (ticket #2829120), and from my conversation so far it sounds like the engineers working on it are receptive to this feedback about the expected behavior in this scenario. 🤞 |
Beta Was this translation helpful? Give feedback.
-
Just kidding? I tried removing the merge queue rule again and it worked this time: I've gone back and forth with the merge queue rule enabled and disabled multiple times, it definitely seems like it's down to this. I must have just been mistaken when I first said this. So, it is just as @usmonster says on that issue. Well, the merge queue is not optional for us. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the ping again @patrick-knight, but it sounds like you were gone when I originally left this feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Rules cannot be bypassed to enter the queue as of now, this is intentional. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, so it's a feature request: I think it'd be ideal for rules/permissions to apply to merge queues in the same way that they apply to normal merges. I understand that merge queues are relatively new and this use case is relatively niche, but it did prove to be a sharp edge for us. In the meantime, to enable "approval bypass" for automated PRs created by this app, we ended up crafting a Rube Goldberg machine of automated approvals (involving another app approving PRs opened by the first app - because PR authors cannot self-approve) that encodes the same logic we hoped rules would have in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
I'm struggling quite a bit to figure out how to put limitations on semver tags, which seems like it's probably an extremely common desire for open source code, because quite often tags == releases == high risk and not always revokable (e.g. with Go modules). Currently I'm guessing that I should do something like this, with two rules:
I'm not yet confident that works, because the fnmatch documentation seems rather poorly suited for this kind of goal, and there doesn't seem to be any reasonable way to check it without pushing a bunch of test-tags somewhere. But assuming that works, it leads to rather annoying cases like: Is there a better way to do this? Could I request a semver-specific thing, since semver tags are incredibly common, well defined, often have major side effects, and are not particularly fnmatch-friendly? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the absence from this thread. Thought it went too quite here but was missing notifications. What you've laid out works and is a challenge with fnmatch, one alternative with GitHub enterprise would be using commit metadata rules which can limit control commit data via regex patterns: https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#ensure-tag-names-use-semantic-versioning |
Beta Was this translation helpful? Give feedback.
-
|
The newest status check interface seems to be broken.
It seems like we can not set up, remove, or add any checks. This is after resetting them all |
Beta Was this translation helpful? Give feedback.
-
|
Someone else experienced this on reddit: https://www.reddit.com/r/github/comments/1erv40q/error_adding_codeguru_security_scanner_as/ |
Beta Was this translation helpful? Give feedback.
-
|
Ok I've discovered the root of the problem, trying to enable CodeQL checks For anyone else reading this: we had to change the source from "Github advanced security" to "github actions". hopefully this actually works |
Beta Was this translation helpful? Give feedback.
-
|
This broke recently, it was working previously.
yields the error on save:
we can try to work around the error and set "GitHub Actions" it saves:
but it's actually not workable, because on PRs I see this:
Changing the source to "Any" saves successfully AND protects the branch:
One thing that's worth adding (probably the reason for this breakage) is that there's a new section at the bottom:
|
Beta Was this translation helpful? Give feedback.
-
|
🫠 this should be all resolved now, correct? |
Beta Was this translation helpful? Give feedback.
-
|
We are facing an unexpected behaviour (despite documented but it still doesn't make much sense) where a ruleset is setup to check commit messages format on specific branch and PR merge strategy of |
Beta Was this translation helpful? Give feedback.
-
|
That's a great observation. We are aware of that issue and are working on some enhancements there -- stay tuned and thanks for the feedback! |
Beta Was this translation helpful? Give feedback.
-
|
One next step to this was landing this change: https://github.blog/changelog/2024-12-04-pull-request-merge-method-rule-public-preview/ |
Beta Was this translation helpful? Give feedback.
-
|
In our rulesets, we allow certain automation service accounts bypass the rules, but they must be in a GitHub team. Ideally, that team could be marked as |
Beta Was this translation helpful? Give feedback.
-
|
That was an intentional decision to not support secret teams here. It would have lead to a situation where it would have not be possible for admins to know why code was merged if they couldn't see a secret team or its members. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this has been requested before, a colleague of mine had a couple of interesting ideas regarding the "require a pull request before merging" setting which we currently enforce
What if there could be sub-items of this? e.g:
|
Beta Was this translation helpful? Give feedback.
-
|
Good call out we're looking into this in conjunction with the PR teams. No specific to share yet but on our mind. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this great feature. I’ve heard that a key advantage of this feature is that anyone can now view the ruleset. However, it seems you need to know to look at direct URL https://github.com/〇〇/rules to see the list. (Alternatively, a “view rules” link appears when a merge is blocked.) I would prefer a direct link to the rules. (ex. https://github.com/〇〇) |
Beta Was this translation helpful? Give feedback.
-
|
You can also access them from the branches page: |
Beta Was this translation helpful? Give feedback.
-
|
I think there is a bug in the rules insights page. |
Beta Was this translation helpful? Give feedback.
-
Hi, What i personally noticed while ago, that for some reasons on Org level Rule Insights are more "correct" than on repo level. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, I do have access and I actually viewed the insights on Organization level. |
Beta Was this translation helpful? Give feedback.
-
|
The goal here is at the highest level of the insight to show the fail state and then in the details showing the specific outcomes of a specific ruleset. |
Beta Was this translation helpful? Give feedback.
-
|
We are trying right now to migrate to RuleSets from Protected Branch Rules, but hitting multiple blockers right now :/ We give all users write permissions on repos and than give specific teams permissions to actually merge the PRs which target the default branch. With Branch protection rules we have solved this via: Our first attempt has been to use a Branch RuleSet with "Restrict updates" enabled and the teams which should be allowed to merge added on the bypass list. Though this leads to that in the normal workflow the bypass utility has to be used. So the next attempt has been to combine both:
Deactivating the Merge Queue allows me to merge changes, so not an issue with my permissions as I understand. But with moving the MergeQueue settings on the BranchProtectionRules we have lost the ability to bypass it, e.g. for oncall. I hope this helps 😅 |
Beta Was this translation helpful? Give feedback.
-
|
+1 on this. We went through the exact same flow. Did you end up finding a way to use the merge queue w/ bypass enabled and w/ restricting who can add to the merge queue? |
Beta Was this translation helpful? Give feedback.
-
|
I haven't found a way outside of giving users "admin" permission, which is a show stopper for compliance reasons. |
Beta Was this translation helpful? Give feedback.
-
|
After implementing the setup described in this post
We can no longer add PRs to the MergeQueue via API ( {
"data": {
"enqueuePullRequest": null
},
"errors": [
{
"type": "UNPROCESSABLE",
"path": [
"enqueuePullRequest"
],
"locations": [
{
"line": 9,
"column": 3
}
],
"message": "Pull request Waiting on code owner review from myOrg/myTeam."
}
]
}Is returned even though |
Beta Was this translation helpful? Give feedback.
-
|
Hey @secustor To clarify a few things that seem like the core of the challenges here?
Just wanted to get a succinct summary to pass on to folks with more knowledge about the merge queue. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @patrick-knight, thanks for coming back. We want to bypass CodeOwner approval with an automation ( Github App ) while using MergeQueues. |
Beta Was this translation helpful? Give feedback.
-
|
An acceptable solution for this scenario would also be the ability to add Github Apps to CODEOWNERS files. Which is as of writing this also not possible. |
Beta Was this translation helpful? Give feedback.
-
|
Feedback on "Require status checks to pass": searching for a check is hard. If I want to know what options are available, I have to start typing before I get information. And that you have to type is not even clear from the UI. I was breaking my head for ten minutes trying to figure out why my test was not visible (was it to old to show up, did I misconfigure something). This should a) be better to understand and b) just fill the list when I click on the dropdown!
|
Beta Was this translation helpful? Give feedback.
and others
-
Hey, Y'all!
I’m excited to announce that Repository Rules are now Generally Available! 🎉
❓ What does this mean?
Repository Rules are an evolution of our branch and tag protections, designed to scale more efficiently. These rules make it easier to protect branches and tags in your repositories and allow everyone collaborating on a repository to understand the rules more readily.
For GitHub Enterprise Cloud customers, you can enforce these rules across your entire organization, ensuring consistency and security. Plus, there's an evaluation mode that lets you try these rules in a 'dry run', helping you understand the impact of new rules before they become active.
📑 Want to learn more? Here are some resources:
❔ Still have queries?
💯 A massive thank you to everyone in the community, the feedback and engagement has been invaluable.
🐛 Known issues:
Some of the more common or noteworthy issues we are tracking:
Only Organization owners can create and manage organization rulesets.There are now org customer roles which include a role for rulesets.No merge queue support at the momentNow GA!Beta Was this translation helpful? Give feedback.
All reactions