Repository Rules GA Feedback #61107
Replies: 44 comments 130 replies
-
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.
-
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.
-
Hello, Regarding the ruleset bypass subject, is there any way we (or an app/bot) can read out the status of the PR as in it being mergeable because of bypass rules in a ruleset? I tried investigating the Github API's to see if i can somehow figure out if that is the case. When i am on the bypass list and when i am not gives me the same results from the Github PR API:
Both responses are completely identical even though in the GH UI i can see the checkbox and merge the PR by hand. Is there any way we can check if the ruleset is by-passable? Or will there be such a feature in the nearby future implemented on the API? Thanks! |
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.
-
Apologies if this has already been mentioned, but I couldn't find anything after searching for "commit" and "bypass". When setting up a metadata restriction for commit message formatting to make sure a Jira ticket is included in the commit message, it seems that there's no way to exempt bot users from that rule, is there? Specifically, I can't see a way to bypass the rule for dependabot, since it's neither an app, nor a team, or an actual user that we could add to a team to exempt. We'd also prefer to not update dependabot configuration to prepend a dummy ticket number in PR titles. Is there a way to bypass rules for dependabot? |
Beta Was this translation helpful? Give feedback.
-
It would be great if tag protections would include the ability to require the tag to be signed itself, not just the commits it refers to. |
Beta Was this translation helpful? Give feedback.
-
"Require status checks to pass before merging" blocks new branches from being pushed w/o a PROur project uses Status Checks from TeamCity. We have found a situation where having a new Rule "Require status checks to pass before merging" prevents a branch from being created by a push.
The result is that the branch is rejected due to the "Require status checks to pass before merging" setting. This is despite the fact that there is no merging going on because we are branching off of Expected BehaviorChecking "Require status checks to pass before merging" only applies to PR merges and does not block new branches from being pushed without a PR (since "merging" is not happening). The behavior should also be consistent with the classic Branch Protection in order to avoid confusion when users are migrating to Rules. |
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
hi. I created ruleset for default branch with metadata restriction that checks commit message by regex to convey conventional commit pattern |
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.
-
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.
-
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.
-
I've found a use case where the PR checks are not working I get 422 error
|
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.
-
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.
-
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.
-
@patrick-knight I made a post about this in the "Repository Rules Public Beta Feedback" discussion and I remember you were positive towards the idea, I can't seem to find the comment now as it has drowned in other comments. Wondering if this is still interesting? The gist of it was if you are still open to the idea of "context aware" branch protections based on CODEOWNERS E.g. a repo with the following structure (terraform or other IaC
CODEOWNERS: * @myorg/admin-team
*.md @myorg/admin-team @myorg/project-team
platform/dev/** @myorg/admin-team @myorg/project-team
platform/test/** @myorg/admin-team @myorg/project-team
platform/production/** @myorg/admin-team @myorg/project-team Essentially I use code owners in my repository rules protection per now to "require approval from codeowners". |
Beta Was this translation helpful? Give feedback.
-
When creating a ruleset that enforces linear history, is it expected that users in the bypass list are still blocked from creating merge commits? I configured a ruleset in Evaluate mode to see how it would work, and as far as I can tell, regardless of what Teams/roles are configured in the bypass list, all users fail the check when they push merge commits. Is this expected behavior? It seems like a bug. What I want to do is allow a select few users to do merge commits and require others to do only squash merges. I want this because we have an automated branch sync process, so we want to allow merge commits, but when creating new commits against the "sync target" branch, we don't want to allow most contributors to accidentally click the "merge" button in the UI instead of the "squash merge" button. It happens. All. The. Time. So much so that we removed everyone's permissions from that branch, and only a select few people get to click the buttons for that branch. I am hopeful that rulesets can address this. |
Beta Was this translation helpful? Give feedback.
-
Beta Release - Requiring workflows with Repository Rulesets!
|
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.
-
I could do with some help with this feature. For a given branch I'd like to enforce checks only for commits that have occurred since a branch was created. As an example I have 2 rules setup:
However these two rules conflict because of previous branches having been merged means merge commits exist in the history and therefore when a new branch is created from the default branch and pushed the "linear history" rule fails. Can rules only be enforced on new commits? That is commits that only exist on the new branch and not the parent branch. |
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