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

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

Appreciate the insights y'all!

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

Not a the moment @olivierboudet.

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!

@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?

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

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)

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

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

🔜

We're picking up that work this sprint @stasostrovskyi

Any update on the OP ie bypassing from github actions?

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.

Could you elaborate on what you mean by dynamic?

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

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

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.

@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.

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.

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

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.

@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?

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)

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!

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

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.

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.

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

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.

@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.

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

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.

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.

Thanks! That helps!

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.

👋 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.

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

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.

This is now in public beta!

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.

@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! 🙏🏻

I work with the relevant team making these enhancements 😄

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...)

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.

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

That's how I understand it, yes.

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.

@patrick-knight thanks for clarity.

@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.

@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.

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

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.

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

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

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

@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.

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.

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.

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.

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.

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

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?

@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.

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

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.

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

@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?

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.

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.

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.

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.

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.

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.