Repository Rules GA Feedback #61107
Replies: 44 comments 130 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.
-
Looks like when comparing to Branch Protection, it is currently missing the |
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.
-
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.
-
I've found a use case where the PR checks are not working I get 422 error
|
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.
-
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.
-
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.
-
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 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.
-
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.
-
I am not able to add Edit: I checked via the developer option, and it gives a |
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.
-
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.
-
Beta Was this translation helpful? Give feedback.
-
Is there a way to bypass metadata requirements for merge commits? One of our teams has a workflow where they open a daily PR from one branch to another. However, we have the requirement that any commit message matches a Jira ticket format. They've run into two issues:
We're transitioning from Bitbucket, which allowed these sorts of requirements but skipped checking merge commits. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Similar to this issue, but maybe not exactly the same? We squash-merge into one long-lived branch (via requiring linear history), and we'd like to use a repo rule on commit metadata to enforce commit message formatting (to start with a ticket number). We also require all changes to be made via PRs, so direct pushes to the branch don't happen. Expected behaviour
Observed behaviour
This makes the rule basically unusable, as requiring people to force-push to fix commit messages within a PR adds too much friction. I think what we'd like is
|
Beta Was this translation helpful? Give feedback.
-
After migrating from required workflow to repository ruleset, we have run into an issue where the required check is duplicated and the duplicate check is marked as expected and gets stuck in Another weird behaviour is that if you go through details on the required check that succeeded and then summary and then click the name of the yaml file associated with the ruleset, it gives a 500 error. Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
I would like an improvement to the required status checks logic or deployment logic My orgs repositories mostly use Github flow for branching. I am trying to set up a branch protection towards my main branch which
This works fine if you have a single build/deploy workflow in your repo, but not so much for multiple workflows where you use path filtering. With the current experience the recommendation is essentially to skip path filtering, otherwise you can end up in a situation where "required status checks" have not completed. The current recommendation triggers a lot of workflows and can add a lot of unncessary static to github actions logs. I know it is possible to add I also tried using Essentially I would like more flexibility in specifying required workflows. The implementation could be as simple as status checks supporting operators such as |
Beta Was this translation helpful? Give feedback.
-
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-linear-history says (emphasis mine):
I understand the part about pushing commits to a branch, but what does "pushing commits to tags" even mean? |
Beta Was this translation helpful? Give feedback.
-
We just tried to enable Require linear history on our monorepo (some of our CI checks don't play very nicely with merge commits and developers get in a mess with it - we are using squash merging at actual merge time), but we had to revert the setting because there are some merge commits far back in the history before we changed the settings and any merge commit in the branch being pushed causes the rule to deny the push. So nobody could push anything. 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.
-
Can someone help me with to bypass branch projection rules with Code Owner Review? I have already checked this post but did not worked out. My Ruleset Settings are:
Renovate Approvers are automaticaly approving the Pull Request and are allowed to bypass the protection rules. But the pull request is still not auto-merged. As I know Apps are not allowed in the Codeowner-File, thats why we chose this way via the bypassing and Rulesets. Is there a limitation with the protection "Require Review from Code Owner" and bypassing? |
Beta Was this translation helpful? Give feedback.
-
Hello everyone! I've been checking but I can't find any related comments. Is there any reason why named users cannot be added to the bypass list, like we can do from branch protections? Is this something that is planned to be added to the rules feature, or is this use case not going to be allowed? We have several service users (not GitHub apps) who need to bypass the pull request protections, but we see that it is not possible to add them nominally, without adding them to a group or role in the repository. Thanks! |
Beta Was this translation helpful? Give feedback.
-
I just ran into some trouble trying to enable the functionality I found documented at the linked URL. Can you describe the status of the known issue? The UI seems to lead me to believe that this works but once enabled I can't add any PRs to the queue. Once the UI has updated to show that requirements have been satisfied, clicking 'Merge when ready' returns an error complaining that the PR is in a clean status for some reason. |
Beta Was this translation helpful? Give feedback.
-
Hi, For us, it is relevant for the use case when we evaluate Metadata restrictions to get "Conventional commits", but we start with not enforcing the developers to follow. Some kind of grace period when we can teach them that they make mistakes and need to improve. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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.
-
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 in beta!Beta Was this translation helpful? Give feedback.
All reactions