Repository Rules Public Beta Feedback

[patrick-knight]

Note

Please move new discussion topics to the GA post! Thanks!

We want to hear from you on how we can improve repository rules!

Repository rules are GitHub's next evolution of branch protections to help make your repositories more secure and compliant at scale.
Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place. There is also an evaluate status where you can run rules in a "dry run" mode to help understand the impact of adopting new rules before they are active and enforced.

If you’ve had a chance to try out the repo rules that are now in public beta, we’re curious to know your thoughts and how we can make this feature work better for you!

🐛 Known issues

Some of the more common or noteworthy issues we are tracking:

• Organization rules do not currently support “Require deployments to succeed before merging”
• Only Organization owners can create and manage organization rulesets.

🚀 Top feature requests

- Collapse “Bypass Mode” and “Bypass List” into single bypass experience
- Enhance repository targeting options
- Support for Apps and Bots to bypass Org Rulesets

• Metadata limits for path and file names

Update June 27th 2023
Changelog

1. UI Updates

• Added a repository picker to target select repositories for organization rulesets.
• Improvements to rule violations in the WebUI and git client.

2. Ruleset Bypass updates

• Bypass can be limited to pull request exemptions only.
• Single UI for bypass, collapsing bypass mode, and bypass list into one experience.
• Support for using repository roles as a bypass type
• Integrations (bots/apps) are now bypassable at the org.

3. API Enhancements

• Add fields for created and updated date
• Permission changes so all repo contributors can query the API for relevant rules enforced on branches.

4. Bug fixes

• Linear merge history could block bypass
• Branches could not always be created when using commit metadata rules
• Tag protections were failing for apps

5. API Change

• GraphQL changes will be delayed by 24-72 hours.
• Breaking Change Remove bypass_mode from the Ruleset object and input
• Breaking Change Add bypass_mode as a required field for bypass actors to indicate if an actor can “always” bypass a ruleset or can only bypass for a “pull_request”
• Breaking Change for GraphQL Change bypass_actor_ids to a new bypass_actors object on the create and update mutations that can accept repository roles and organization admins.
• Add repository_role_database_id, repository_role_name, and organization_admin fields to RepositoryRulesetBypassActor to indicate when the bypass actor is a role or org admin bypass
• “get rules for a branch” REST API endpoint now returns ruleset source info for each rule.
• “get a repo ruleset” REST API endpoint now has a current_user_can_bypass field that indicates whether the user making the request can bypass the ruleset.
• source field for rulesets returned via the REST API will now properly contain the repo in owner/name syntax when the ruleset is configured on a repository, rather than just the repository’s name.

[bewuethr]

Is this enabled for Enterprise? The help page 404s, and the feature isn't visible yet in repo settings.

[patrick-knight]

We're getting the links updated in the changelog.
But you'll want https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets

[bewuethr]

Ah, thanks! I see the feature now, too, I think I didn't look properly before 🙈

[bewuethr]

I'd love for there to be an option to limit merging methods per branch; for example, require linear history on one branch, and prevent squash merging on another branch. This is for the use case where you want linear history on the default branch, and then no squashes on a second long-lived branch used for production deployments.

The only option currently is "require linear history", as far as I can tell.

[patrick-knight]

Appreciate the insights y'all!

[olivierboudet]

@patrick-knight is there some advances on the ability to configure different rules by source branch ?

[patrick-knight]

Not a the moment @olivierboudet.

[JonoNiemann1]

almost a year later and im having the same issue

Im not able to override approvals based on metadata, i have an automation user that id like to require a single approval for on prs

2 rulesets enabled

1.) Require a single approval where committer email is xyz@whatever.com
2.) default ruleset requiring 2 approvals, (have even added an exception here in metadata to say where commiter email != xyz@whatever.com

the layering still seems to require 2 approvals...

No branch protection rules enabled, rulesets seem like a cool idea in theory, but the practical applications are severely lacking unless im doing something wrong...

Super frustrating!

[patrick-knight]

@JonoNiemann1 The behavior you are after is a "if this then that" style of rule? So if this "type of actor" is presented they get a different set of rules?

[dnr-len]

It would be nice to show in Branch Protections if a ruleset is already applied to a branch. So that someone who may not have full admin rights (and may not know about rulesets) can see that there is already a ruleset. And possibly show if its an Org level and/or Repo level
A section that has just a list. Something like
Heading: Branches with Rulesets
Body:

• develop <link to view ruleset>
• main <link to view ruleset >

[patrick-knight]

Good callout! In those cases would a link from the branch protection page to rulesets suffice instead of a full overlay of rules?

[dnr-len]

You would have to make sure that Rulesets can be viewed (I don't have a way to test this) by users who may only have write + ability to modify Branch protections, permissions.
Yeah. If it ends up being a Callout of "Some rulesets apply to branches in your repo <link to rulesets page>"
But, I could also see this being not verbose enough. (As i typed <- sentence I found the filter by branch button in rulesets)

[patrick-knight]

That level of visibility is a tenant of repo rules and so the visibility would extend to folks with the ability manage branch protections.

[cvergne]

Nice UI, congrats for the work !

Is there a way to add bypass to Github Actions Bot ? Or still not ?

Thanks :)

[stasostrovskyi]

Awesome @patrick-knight , thank you! Last piece of the puzzle for us would be to allow Apps/roles bypass org rules

[patrick-knight]

🔜

[patrick-knight]

We're picking up that work this sprint @stasostrovskyi

[passcod]

Any update on the OP ie bypassing from github actions?

[patrick-knight]

Nothing new. This isn't going to be a quick lift as there are some difference in auth models and permissions here we need to think through.

[OneCyrus]

are dynamic required workflows also something which this will enable?

[patrick-knight]

Could you elaborate on what you mean by dynamic?

[OneCyrus]

Could you elaborate on what you mean by dynamic?

require only the workflows that are actually triggered (e.g. path filtering, ...)

basically this: https://github.com/orgs/community/discussions/13690

[patrick-knight]

We are working on enhancement to rules with workflows so keep an eye for update around that in the future.
https://github.com/orgs/community/discussions/52652#discussioncomment-5641023

[dghubble]

As of today, ruleset's still wait for statuses from jobs in workflows with path conditions, even for PRs where that check isn't run.

[lszomoru]

Are there any plans to automatically convert branch protection rules into repository rules?This would significantly help with surfacing this information to repository contributors as branch protection information is not available while repository rules are. Thank you!

[traya1]

@patrick-knight Sorry to ping you, but on the topic of converting branch protection into rules, is there an ETA on when that might happen? I know it's currently in beta but just curious if it's known when the change will happen.

[patrick-knight]

Right now our thinking is to offer tooling is the future to support moving from into rules there isn't an ETA on offering that just yet as we have also not decided on a sunset date for branch protections.

There are some "decisions" we want folks to think about through in the conversation process, such as

• does it make sense to migrate in 100 of the same branch protection rules, when one org rule would work
• And how to handle to differences in bypass model in branch protections to rules might also not be a 1:1 mapping.

[stasostrovskyi]

I guess it's also interesting whether one converts branch protection into a single rule or a combination of rules.

[rgoodwin]

How do you setup status checks on branch protections that can be added to Organization level rulesets? I tried creating a test ruleset and then enabling Require status checks to pass before merging but when I do no checks show up to select (No status checks found appears). Note I tried this at both the Org and Repo level.

This is a very useful new set of features. So excited to try it out. -Thanks

[patrick-knight]

Workflows is the recommendation for org level actions right now. There are plans to allow of interoperation between workflows and rules at the org level. But you can also leave as any source which is weird.

[rgoodwin]

@patrick-knight Worked for me. So useful. I will be calling the GH API a lot less to setup checks :)

Question. The actual workflow that has to be run as the check must reside in the repo the check is run in. And that workflow from that repo will be run. EG: If the workflow/job has the same name in two repos but is different then a different check will be run per-repo?

[rgoodwin]

As far as I've tried, GitHub action cannot be selected as a source. Am I doing something wrong or we are supposed to use required workflows instead?

I do understand it is going to work anyway and source will probably be updated automatically, but it feels a bit weird..

@stasostrovskyi I thought it was a bit weird at first. But (if I'm understanding correctly). It would allow dev's to maintain their own checks in repos but enforce that they be run.

At the same time @patrick-knight it would be pretty great if we could also reference reusable actions or workflows in the future (cleaner and more enforceable)

[stasostrovskyi]

In case of github action it makes it very easy to "trick", since you can put a noop in a github action with same name and get along with it. Not saying we shouldn't trust our developers, but it does feel a bit weird, especially when you have a feature nearby that addresses exactly this problem but lacks flexibility when it comes to targeting repositories by pattern. But it's a great step forward anyway!

[patrick-knight]

The future path is to work on having a tie in with Required workflows to help mitigate some of those concerns.

[ahatzz11]

This is awesome to see natively from GitHub! A few things:

1. I'd love the ability to sort by the outcome in the insights tab. e.g. "Show me everything that failed" or "show me everything that was bypassed". We have a very large organization (1000+ repos) and many many events. More powerful filtering would be great.
2. Add larger page sizes on the insights tab. This kinda relates to point 1, but we have many many events and scrolling through 10 at a time is a bit tedious.

Super excited to see this functionality grow, this solves many headaches we have in our organization.

[sullimander]

I agree that filtering by outcome would be great. I would also like to see some graphs of our pass/fail/bypass over time, so we can see if things are improving.

Another feature that would be useful is a way to get a list of users who bypassed or failed a rule during the given time period.

[sullimander]

One other thing I noticed on the insights page. When filtering by a specific rule set, the Pass/Fail/Bypass badges doesn't reflect the ruleset that of the filter, but all rulesets on that commit. I created a ruleset to test restricting commits on email address, but many of them showed with a "Fail" badge. When I drill into the details, the email check passed, but some other rule failed. I would expect that filter to update the badge for the ruleset I'm filtering by.

[patrick-knight]

Thanks @sullimander! We have some improvements we need to get to on insights, but next we'll focus on APIs/Webhooks.

[patrick-knight]

Hey @ahatzz11 and @sullimander,

There is now a beta for a REST API endpoint for Rule Insights. Feel free to send me an email at at github.com if you're interested in early access.

[fallard84]

@patrick-knight Is there any timeline for adding the rule insights to webhook or audit logs? Being able to review rule bypass after 30 days would be a lot easier if we can stream the audit logs to an external system.

[pg9182]

This is much nicer than the existing branch protections, especially with the increased flexibility around selected branches, the rules applying to tags, and the public visibility into applicable restrictions.

I'd like to be able to view the restrictions implied by other rulesets applicable to the chosen branches while editing/creating another one.

[patrick-knight]

That makes sense. And just to confirm that would help with ensure rules don't overlap?

[pg9182]

Yes, it would help ensure rules don't overlap. Earlier today, this became a problem when there were already existing rules denying access broadly, but I wanted to add another team without those restrictions for a more specific branch pattern. I ended up having to look at all the other rulesets quite a few times to ensure there weren't other rules blocking it, excluding the specific branch pattern from the broad rulesets, creating a new ruleset with that branch and the required restrictions/bypasses, then looking again to confirm that the correct restrictions still applied to the other teams.

I'm imagining some sort of preview button/hovercard/etc beside each restriction if another ruleset contains it and overlaps with the branches, showing which branch patterns (or at least some examples derived from the union of the current examples and the examples from the other ruleset) overlap and who can bypass it.

Another (potentially cleaner) way to support this kind of use case would be to add test case functionality for a subset of the restrictions, where you could assert that a specified user/team would be allowed/denied push/force-push/delete/create access to a (theoretical) branch with a specified name. This would reduce the risk of new rulesets accidentally being over-restrictive, while also increasing confidence that a ruleset works as intended when combined with the others. I'm imagining a section below each ruleset where you can add a list of tests, showing warnings for failed tests (and which rulesets deny it, if it's failing due to a denial) on both the ruleset and rulesets pages.

And, the simplest way to solve the specific issue I had would be to have search/filter functionality to find which rulesets apply a restriction to a specific branch name for specific teams.

[pg9182]

Actually, an even simpler way to eliminate the need for me to make most of those complex rules in the first place would be to allow making rulesets only apply to specific teams rather than exclude them.

[patrick-knight]

Thanks! That helps!

[lenaschoenburg]

Are you planning on integrating merge queues? Currently it seems like merge queues can only be activated through branch protection rules but it would make sense for repository rules too.

[Aeolun]

I think it's kind of important that some of these new Github features are completed, in that they actually work with all the other existing features of Github.

Having 5 different half baked features help nobody, and makes it hard to figure out exactly which combination of half baked features you need to use to get the desired result.

Rules seems to solve almost all of the issues that couldn't be solved in the branch rules due to their design, but now there's stuff that's still stuck in branch rules anyway because it's not implemented here.

[patrick-knight]

👋 Been a bit since I followed up here, but wanted to share we are planning a public beta for the merge queue in rules slated for mid-late January. One of the area we spent some time on was ensuring the queue was correctly represented in rule insights. And wanted to give a quick peek at that work.

[thomassimko]

@patrick-knight is there any update on the merge queue public beta?

[patrick-knight]

Thanks for checking in and sorry about not being proactive.

We had to delay the beta due to some bugs but are on track to release the beta next week.

[patrick-knight]

This is now in public beta!

[sandstrom]

Nice work on the new repository rules. Very useful! 🏅

However, the functionality "Dismiss stale pull request approvals when new commits are pushed" doesn't work well with fixup! and squash! commits -- which is a common review workflow.

Feature Request

During a PR review, the PR author will often add 1-2 fixup commits to address reviewer concerns. The purpose for using fixup commits is that the reviewer can easily see what's changed since the last review. The reviewer will typically approve the PR after the fixup commits addressing concerns have been added.

It would be good if the PR approval wasn't dismissed in the scenario where commits are squashed, but no actual files has changed. I.e. there are no code changes, only commits being moved around or merged.

Example Scenario

1. A developer adds a PR with the following commits:

- Add first name to user model (a931bb)
- Update user icon (72ce49)
- Adjust user profile wording (eff2aa)

2. During the review phase, the author adds two fixup commits, to address concerns that came up. The commits are now:

- Add first name to user model (a931bb)
- Update user icon (72ce49)
- Adjust user profile wording (eff2aa)
- fixup! Add first name (1457e3)
- fixup! Adjust user profile (bb2445)

3. The reviewer adds approval to this PR, everything is good!

4. Now, the problem is, if the author would merge the two fixup commits, the approval would be dismissed as stale, even though there is no difference in the code, only two merged PRs.

Solution: Would be great if a SHA-hash of the entire diff (or each individual touched file in PR) was compared instead, and if they are identical the existing approval is not considered stale, even if commits have changed.

More background and discussion

https://github.com/orgs/community/discussions/12876

(this issue already have a 65 upvotes, so I'm not the only one who find this annoying)

[patrick-knight]

The underlying logic of this rules did not change so we brought forward the existing, maybe not preferable behavior.

We are working on a number of changes to "strict reviews" (dismiss stale and last pusher) to make it easier to carry forward votes in scenarios like this. I won't do this topic justice in a discussion post so will share more when we roll out these changes.

[sandstrom]

@patrick-knight Alright, sounds promising!

I understand this may be orthogonal to the feature you are building here, but wanted to mention it to get a Githubbers eyes on it. And that I succeeded with 😄

Great if you could mention this issue to the relevant team or product owner.

For us, this is a pain point around PR approvals and fixup commits. Basically, what we usually do is to not use the 'dismiss stale' mode, because it's too much hassle (effectively we'd have to review everything twice). But I think the "SHA hash of diff" approach mentioned above could alleviate that problem.

Anyway, thanks for reading and replying! 🙏🏻

[patrick-knight]

I work with the relevant team making these enhancements 😄

[luxaritas]

Something I find interesting: When updating a PR, it won't dismiss an existing review as stale, but it will trigger the "reviewed by someone other than last pusher" check.

A related issue: What if I'm in a repository with one other person, and I want to enable that rule? If I submit a PR and the other person updates, it's now impossible to merge since I can't review my own PR. (This also winds up being relevant if I make a PR on the behalf of someone else, but that's admittedly a bit harder to validate...)

[patrick-knight]

A related issue: What if I'm in a repository with one other person, and I want to enable that rule?

You'd probably want to have bypass or admins permissions in that case.

[beingminimal]

I am trying to implement repository rules at org level.
And as per this document if i am github team user then i can use this feature at org level.
But i am not able to use it and it shows the message as shown in screenshot.
Please help me to solve this and use this.

[beingminimal]

ok so at repo level i can use but at org level i can't use in team plan right?

[lars-reimann]

That's how I understand it, yes.

[patrick-knight]

Correct, Org wide rulesets are only available with a GitHub Enterprise Cloud plan. Teams allows for rulesets on both public and private repositories, much like how branch protections are licensed today.

[beingminimal]

@patrick-knight thanks for clarity.

[unicornware]

@patrick-knight

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.

[lars-reimann]

I'm not sure about the behavior of the "Require linear history" rule. If this ruleset is disabled (or bypassing it is allowed), I can bypass the remaining rules as a repository admin:

However, if I enable it and disable bypassing, this is no longer possible:

I'm aware that the rule then applies to admins as well. The intention is that admins may push directly to main but should not be able to accidentally push merge commits. But according to the docs, a squash & merge of a pull request should be fine. The rule does not seem to take the merge method into consideration, however.

As an aside: It would be nice to see directly that the "Require linear history" rule is preventing the merge.

[pg9182]

@patrick-knight, update on my case: it doesn't seem related to the "Require linear history" option, but it seems that bypass list doesn't work for allowing PR merges when it blocks push/create/delete for a branch, with bypass enabled for a specific team. See my new post here.

[patrick-knight]

Missed updating this thread. It's a UI bug we have an issue open on but is not is not present in the API.

[patrick-knight]

Hey y'all we have a fix for this we're going to roll out int he next week or two with a batch of other changes. If anyone is interested in early access let me know.

[luxaritas]

Thanks for the update! No need to have it early, but will verify it fixed what I saw once I hear it's released

[lars-reimann]

"Require linear history" works as expected for me now after the recent update. Thanks!

[akshaal]

Enabling "Require status checks to pass before merging" and selecting a status check results in a brief popup message "Validation failed." without any other useful info. It seems like github web ui does POST to https://github.com/org/repo/settings/rules/ID and receives 422 "Unprocessable Entity" with nothing else but { message: "Validation failed." } in the response.

[patrick-knight]

Appreciate all the feedback around this. We've got our designer tee'd up to streamline this experience.

[masklinn]

@patrick-knight I just want to say that I do appreciate the checkbox system compared to the "legacy" branch protection, for repositories with large test matrices the old system was absolute hell when the matrix changes and the required statuses have to be updated.

However the new version is not ideal either, it jumps a lot as every new status will move the completion dropdown (or drop-up when there are too many statuses, which is worse) left/right, and it's easy to miss-click and have nothing happen (? not entirely sure but I had weird behaviour when clicking the text instead of the checkbox, this is using Safari).

Try creating a repository with a dozen statuses or two and try to set a bunch of them as required.

Maybe instead of a FAYT dropdown it could be more of an actual table, to more easily get an overview of valid statuses? By default all statuses seen on the repo would be displayed in the table, rows could be removed (for outdated statuses or statuses we don't care about), or added (for future statuses), and rows could be selected or deselected independently of their presence.

Also maybe something more project-table like could be used, so the test matrix could be better reflected / utilised? (though I don't know if that's information github keeps internally) e.g. let's say I have a job with a matrix of 4 versions of the host language and 3 versions of a dependency, I'd like to select all instances of the job, then deselect say, the instances for the pre-release of the host language (because that's a useful signal but not a merge requirement).

Currently I need to select 9 instances of the job individually, which is better in the new UI than the old, but still not amazing.

[patrick-knight]

Thanks @masklinn for the feedback! We work to find the right balance for this feature so it also works with 100s of checks from varying sources to occasions like you called out.

[Aeolun]

I have to say that I think it's a bit bizarre that this hasn't yet been addressed. We're 1.5 months on, and I just ran into the same problem. The same page for adding organization rules doesn't have this weird behavior, and just immediately adds the test you've specified.

[patrick-knight]

I appreciate the feedback @Aeolun, we recently improved some of the error messaging when saving rulesets in this situation. And have designs for a future up date here but there are a few other things we plan to address first.

[tfisicaro]

Awesome features!

For the metadata restrictions I think it would be useful if the value which breaks the rule(s) is shown on the insights page or to the user that breaks the rule.

[patrick-knight]

We are working on improvements to the notifications users see, but in insights admins should see some context on what the requirements of the rule are. If not let me know and we'll take a look.

[patrick-knight]

We did land come enhancements to new file creation warnings and we have a PR queued up for editing existing files.

[nhed]

It would be nice if a tag ruleset could require tags of a certain pattern to be annotated
(extra credit - if tag could be submitted for a review)

[patrick-knight]

Great call out on the annotations for tag. The reviews part is very unlikely to happen.

[fproulx-boostsecurity]

Just tried it and I really really like it. It's very very flexible and powerful.

But, I miss the Require review from Code Owners feature from Branch Protection. Because we like to segment our PR approval auto-assignment with it.

Also, not clear that Require approval of the most recent reviewable push , etc. is part of new Repo Rules

[patrick-knight]

I saw your post over in the GA announcement and replied there.

TL;DR those rules are both available.

[nzin]

is there a bug with graphql on

conditions {
  repositoryName {
    exclude
    include
    protected
  }
}

When I use the UI to configure:

when I am fetching rules via graphql I get:

Am I doing something wrong or it is a bug?

Regards,

PS: if I target selected repositories (by ids) it works fine

[patrick-knight]

Sorry for the delay in getting back to your @nzin thanks for sharing. It's a bug and we've got an issue open tracking it

[nzin]

btw, another question @patrick-knight . Using graphQL:

• the repositoryId.repositoryIds, is not sending repository ids (int type, like 661627952), but the node id (string type, like "R_kgDOJ2-kMA").
• but when you create a ruleset (using REST API), you have to specify the repository id (int type, like 661627952).
  I find it inconsistent, and I was wondering if it is intentional?
  The GET/POST REST API is more "consistent"

Regards,

[nzin]

hi @patrick-knight , any news regarding this strange behaviour/bug? (i.e. not about repositoryName but repositoryId).
I can provide screenshots if needed.

Regards,

[patrick-knight]

Hey @nzin I was out on PTO for a bit. so let me follow up with the team on this one.

[patrick-knight]

the repositoryId.repositoryIds, is not sending repository ids (int type, like 661627952), but the node id (string type, like "R_kgDOJ2-kMA").
but when you create a ruleset (using REST API), you have to specify the repository id (int type, like 661627952).
I find it inconsistent, and I was wondering if it is intentional?
The GET/POST REST API is more "consistent"

It is intentional and inconsistent from REST as our graphql API specs does require references to “id” be limited to a “node id”

[patrick-knight]

Repository Rules are now GA!
https://github.com/orgs/community/discussions/61107#discussion-5412742

[grahame-student]

@patrick-knight I could see it being useful to be able to specify repos based on which template they were created from.

[patrick-knight]

Could you tell me more about that?

[grahame-student]

Sure.

We tend to have a different 'families' of repos, e.g. python, embedded C for various microcontrollers, C#, etc.
For each of these types I've been creating a base template repo to improve the consistency of our projects.

The organisational level rulesets have greatly helped improve the speed of deploying new repos, however as others have mentioned, linking rules to specific repos can still be a bit tedious.

Being able to link our

• common python related rules to projects created from our python template
• common microcontroller_family_1 related rules to projects from our microcontroller_1 template
• common microcontroller_family_2 related rules to projects from our microcontroller_2 template
• etc

Would help ensure we're following policy from the moment the repo is created, especially once we can set required status checks via the rulesets.
I can see that the generated repos already know which template they were created from, I'm making the bold assumption that would make this relatively easy to detect, of course there's also probably a bunch of gotchas that I'm not considering :)

An alternative might be to enforce repo naming conventions, however renaming already created repos and fixing the consuming repos doesn't seem like a productive use of our time.

More than happy to provide more info if needed.

[ioquatix]

I believe a more general solution to github configuration is required. It should be possible to configure 90% of the settings of a repo from files in the .github directory of the main branch. Rules should be part of that. This way, templates just work, and maintaining repositories isn't tedious work. There are already some GitHub apps that do this, but it should be supported out of the box IMHO. For this specific piece, maybe having the ability to define rules under .github/rules/rule.yaml or something could work.

[grahame-student]

Interesting, I quite like that too. Some thought would need to be put into how they were handled to ensure that you don't get a rogue developer removing rules without understanding the consequence on quality. For example it would be a bad idea to allow a proposed change to the rules to bypass code reviews as that could allow them to introduce other changes without oversight!

There's always more than one solution to a problem :)

[chrispat]

One of the core design goals for rules was to have them enforceable from the organization such that a repository admin can't simply turn them off. This capability is important for organizations that have strict audit requirements. Simply configuring in a repo completely negates that as a repo admin could just change the rules after the fact.

Having the ability to target rules at repositories based on other metadata is currently in progress and I believe that will go a long way to solving this scenario.

[adamxchen]

@patrick-knight We tried this feature and it's really wonderful! I'd like to ask if there's a solution for our case (if it doesn't exist, can use this chance to provide a feedback).

Is there a way to NOT allow PR owner to bypass the rules but others in the team can?

In our case, with the existing branch protection rule, we have many status checks required for any PR targeting to the default branch. Usually, devs in the team don't have Admin permission so they cannot merge the PR until all checks pass and PR approvals is obtained. However, occasionally it's okay to bypass the checks for some PRs when someone approves the change and we don't want to ask Admin to do it every time. We can have an "override" button for devs by leveraging this new ruleset feature, but PR owner also have it, meaning one person can merge the PR w/o any approval or status check, which we want to avoid.

[patrick-knight]

Thanks for the feedback @adamxchen.

Can you talk more about this situation? Is it known in advance when this would occur? Or is it situational? Is there a group of non-admins you can trust to have bypass abilities?

[adamxchen]

@patrick-knight Appreciate your reply!
This is situational. And yes, there's a group of non-admins we can trust to bypass the rules but with the requirement of obtaining approvals first (whether that's a comment or a Github PR approval)

The situation

Say one dev, which is non-admin, renames a bunch of methods in a PR to improve the code reliability and doesn't alter any code functionality so it's safe to merge. However, since some codes are legacy and missing test coverage, the code coverage status check fails and wouldn't allow this dev to merge even with an approval.

This is just one of situations. Sometimes, we've tried hard to add code coverages but due to the urgency of the PR, we want to merge it once approval rules are satisfied, e.g. one approval is obtained.

What we have tried so far

1. Ask the admin to merge the codes or disable the status check for a moment. This is okay but requires admin intervention every time so we want to avoid this
2. Leverage the new ruleset feature introduced by this post, but as I mentioned above, if the PR owner has the bypass abilities, the owner can ignore every rules and merge directly which is no desired.

Ask

I guess what I am asking is whether this ruleset feature can support more flexible bypass models, e.g. only allow bypass status check vs. allow bypass everything.

[adamxchen]

BTW, I can move this post to the GA feedback thread if you prefer

[patrick-knight]

I guess what I am asking is whether this ruleset feature can support more flexible bypass models, e.g. only allow bypass status check vs. allow bypass everything.

Repository rules support layering, meaning you can write a couple of rulesets, one with a bypass list narrowly scoped, layered with another ruleset containing an different bypass list for a different rule.

Beyond that native ability we are continue additional ways to make rules more flexible with permissions and bypass generally.

[Moulick]

I am trying to implement a ruleset for author/commit email that check for emails ending with multiple domain like @companyA.com or @users.noreply.github.com. While the rule matches if I only put one company, it never works when I have multiple companies.

I have tried the below but none of them work 😢

1. .+@companyA.com|.+@users.noreply.github.com
2. .+@(companyA.com|users.noreply.github.com)
3. .+@(companyA.com|users.noreply.github.com)$
4. (companyA.com|users.noreply.github.com)$

[Moulick]

For anyone who got the same issue, Select Must match a given regex pattern and not Must end with matching pattern

[flitzie]

@patrick-knight
Hi Patrick Knight I need some help. I don't know if this is the right channel to post or not. I just give it a try :-)

Setup:
2 rulesets per protected branch:

1. One with "Require a pull request before merging" and
2. 2nd ruleset with "Require status checks to pass before merging" and required status check name (e.g. ci/jenkins/branch).

Problem:
Creating a protected branch (e.g. release) from a git tag or another protected branch (e.g. develop) without code changes works only if the commit hash (git tag or HEAD) has been build by Jenkins successfully before hand.

Use case:

1. The protected branch develop has got the status check success of the required status check name.
2. A developer creates a new feature branch in github.com from the protected branch (e.g. develop) without code changes
3. GH triggers Jenkins, Jenkins starts building
4. Jenkins build has been aborted (e.g. by developer or by the pipeline because the developer has pushed new code changes to the feature branch).
5. The github-sourcebranch-plugin sends status failed and updates/overwrites the status of the status check name (e.g. ci/jenkins/branch) for the protected branch develop.
6. Another developer wants to create a new protected branch (release) from the protected develop branch and is BLOCKED (required status check "ci/jenkins/branch" is failing)!

Workaround is questionable:
So, if a developer wants to create a new protected branch from:

• an older commit (like a tag) and GH does not have a record of this successful status or
• a HEAD commit (e.g. develop) with a FAILED status (because the Jenkins build has been aborted)

then you need developers or admins with bypass permission for all protected branches (release/, master, support/).
BUT when you add developers or admins to the bypass list of the status check ruleset then you actually DISABLE Gated Pull-Requests for everybody in the bypass list. Introducing admins for creating protected branches is not an option for us because they are developers also.

Feature request:
How about adding to the drop-down list of the bypass list (next to "Always" and "For pull requests only") something like "Create branch without code changes"? Because then I could add "role:write" to the bypass list WITHOUT disabling Gated Pull-Requests.
Or how about a check-box "Ignore missing status check"? Because then I could configure the status check name "ci/jenkins/pr-head" as required which is always getting lost due to new commits on the protected branch when pressing the merge button (merge, squash, rebase).

[flitzie]

@patrick-knight I continued my research. Any feedback appreciated. Here is my summary:

In GitHub status checks are checking any git push (branch creations, code changes) to protected branches, no matter what other rule(set)s are configured (e.g. Pull-Requests) or not.

If developers want to create protected branches (like "release/" or "support/") without any code changes and without having bypass permissions of the required status check ruleset then the branch creation most probably fails. If a developer succeeds or not depends on the required status checks name (e.g. "ci/jenkins/branch") of the commit the developer wants to branch out (see my comment above).

To create a new protected branch with a required status checks name (e.g. "ci/jenkins/branch") the following workarounds are possible:

1. Create a feature branch from the protected branch and let Jenkins finishing the build successfully to update/overwrite the status of the origin protected branch in GitHub. Then create the protected branch (e.g. release/*) from the origin protected branch and push it.
2. Create a feature branch from the git tag and let Jenkins finishing the build successfully to update/overwrite the status of the tagged commit in GitHub. Then create the protected branch (e.g. support/*) from the git tag and push it.
3. Trigger a Jenkins pipeline to create the protected branch (e.g. release/*). The Jenkins GitHub App must be part of the bypass list of the status checks ruleset.
4. Configure an admin-team and add them to the bypass list of the status checks ruleset. An admin can now create a protected branch. NOTE: All admins are not gated anymore!

This (protected branch creation) issue occurs permanently when merging Pull-Requests using squash or rebase strategy and having a required status checks ruleset configured which status checks name is only updated on Pull-Request events. Because the status check name (e.g. "ci/jenkins/pr-head" or "ci/jenkins/pr-merge") of previous commits (on the feature branch) are lost. Even the virtual pre-merged commit provided by GitHub ("refs/pull/#/merge") gets lost after pressing the merge button.

This issue is not only related to Jenkins integration, it also affects GitHub Actions!

Feature request:
It would be nice to make the status checks configuration more flexible and fine grained configurable with other settings. For example that I can combine: status checks & pull-request and/or status-checks & branch creation and/or status-checks & branch updates.

This would allow more use cases and better integrate other branching models (e.g. cactus, git-flow).
Don't you think?

[from-nibly]

We have three environment based branches main, rc, and dev. We have branch protections on these with various policy bot policies, but we can't create any of those branches because we'd have to get policy bot policy checks before we can create them. This makes it so developers can't create new repos on their own. We also don't want to continue to have our Platform Engineering team to be on the bypass list.

We don't want status checks to apply to creation, cause our checks have a chicken and egg condition, where in order to have policy-bot status checks on a commit, there has to be a PR to that branch. which can't happen if the branch doesn't exist.

[from-nibly]

put another way it makes the "Restrict creations" checkbox useless (it acts like it's always checked) if there are any PR related status checks that are required.

[patrick-knight]

Beta Release - Requiring workflows with Repository Rulesets!

Available in public beta today, GitHub organization administrators on Enterprise Cloud plans can set up and require workflows to run and pass before a pull request can be merged into an organization’s repositories. This can be enabled with Repository Rulesets!

[grahame-student]

Is there a recommended way of passing repo specific config to a required workflow?

Would it be a repo variable that the required workflow will be able to consume. This would require each repo subject to the required workflow to define the same variable with the repo specific value.

This is one area where I see reusable workflows having en edge as they can defined required inputs.

[chrispat]

Variables are going to be the best way to do that. You can always either code the workflow to check for a variable to be defined and if not provide a default value or you could create a variable at the org with the default value and share that with all repositories.

I think required workflows and reusable workflows a completely different features and have different goals, so I am not sure one has the edge over another in general terms.

[grahame-student]

Understood, I'll look into using variables.

Indeed, required and reusable workflows do seem to be different features, a nuance that blocked me from getting a required workflow for a while :)

What I was trying to achieve was having the project build and execute unit tests as a required workflow defined as policy, but also handle the fact that some repos have multiple unit test projects, which may not be the same between repos, that should all be run.
Using a reusable workflow I can define the common workflow and require an input variable that takes a list of unit test project paths, but I then have to define a branch protection rule in each repo that should use the workflow as a quality gate.

The repo variables may get me most of the way there, but I could see there being issues if unit test projects needed to be added to / removed from a specific branch. I guess updating the workflow to look for a config file may help there.

[chrispat]

For that scenario I would recommend specifying that a config file or a script exist in a specific location in the repository rather than a config variable.

[Apolloluy]

Unable to find a reference at the moment, but I have a protected Ruleset with the syntax targeting release/**/* and "Require status checks to pass before merging" enabled with 2 status checks requested. This is preventing anyone from CREATING a branch with that naming sequence. This seems unintentional as there is an Option in the list "Prevent others from creating commits with this naming" which is unchecked, meaning developers should have the ability to push new branches with this name format when there was not one prior.

This occurs from the Github.com UI and from git push.

[grahame-student]

@patrick-knight / @chrispat
I've got a similar issue, we use

• an equivalent naming pattern in one rule to restrict branch creation
• a rule that requires linear history for branches with the pattern defined in the previous rule

The ruleset insights shows that creating a branch with the required pattern is failing due to the merge commit rule. I'm also unable to specify a bypass for the linear history rule.

[patrick-knight]

@Apolloluy if the check was run and successful from the source branch that should allow for branch creation. Is that not the case?

[Brend-Smits]

Hey @patrick-knight
Are there any plans to provide more details in the 'rule insights' page when a rule fails? Especially when you configure a metadata rule (i.e. committer needs email X), I want to know why it failed (what email address was used to commit instead).
It's currently quite difficult and time consuming to debug when these rules fail.

[patrick-knight]

Thanks for sharing @Brend-Smits, nothing concrete is on the roadmap, but we have discussed showing more detail in rule insights. With the new merge queue rule we did add additional information to ensure that the scenario was clear. So, an area we are keeping an eye towards future enhancements.

[Rebecca-Broos]

Not sure if you're still collecting feedback, but using an organisation ruleset I tried to allow a certain team to bypass branch protection rules set in the repo. The team member however wasn't able to push directly to main, even though the rule was enabled and the team added to the bypass list

[patrick-knight]

Did the team member also have contribution access to the repo? Or where they solely on the bypass list?

[tallior]

I'd like to add my feedback on the ruleset feature, even though i realize it's no longer in beta.

Our dev teams work with branches, and we have a few "special" branch types we'd like to manage access to:

1. Default (develop) - main branch where all work gets merged into
2. Release branches - branches for managing releases
3. Epic branches - long lived branches for large features that could be alive for up to a few months time

Bypass PR requirement (if merging from a protected branch)

For 1-2, there's no real need to keep up to date with the default branch, but for a long lived (epic) branch - there is the need to do so.
In such a case, with the ruleset enabled, forcing a PR into the epic branch, we must create a PR for every merge from the default branch (develop).

As the develop branch contains only work that was already approved via PRs, there's no point in forcing a PR when syncing an epic branch with develop.

It could be nice to be able to do that in some way.

Same goes the other way around -
an epic branch is a long lived branch, where work is only merged via PRs.
Once we'd like to merge back a huge PR from Epic --> Develop, there's no need for another review, as all work was already reviewed.

Would be great to somehow be able to avoid this enforcement.

[patrick-knight]

Thanks for the suggestion and scenario @tallior. There are some concerns we have for these flows where un- or under- reviewed commits could unintentionally land on the default branch.