Repository Rules GA Feedback

[patrick-knight]

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:

• Our blog post provides an overview of the new feature and its benefits.
• The docs give you all of the details about how repository rules work.
• 🎥 Youtube video talking a bit about repository rules

❔ Still have queries?

• Feel free to post here for feedback.
• Previous insights shared on the beta discussions is still top of mind for us as we continue to iterate on rules.
• For bugs or deeper questions please reach out to support.

💯 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:

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

[kevinlul]

For the use case of exempting bots, how do I exempt commits using the default GitHub Actions token from a workflow?

[patrick-knight]

At the moment, there is not support in Repository Rules for bypassing based on Actions due to the nature of the permission and how they can be triggered.

[vibro]

@patrick-knight I am using a Github App token to do the push action, but it's still showing up in the Repo Rules audit log as Github Actions[bot]. See discussion here where I opened a ticket with the push action, but I think it may be a Rules issue.

[patrick-knight]

Hey @vibro,

Two things, are the insights correct when using "normal" git commands. And can you also opt to try this update to your workflow:

- name: Push changes
        uses: ad-m/github-push-action@v0.6.0
        with:
          github_token: ${{ steps.generate_token.outputs.token }}
          branch: ${{ env.BRANCH }}

[fproulx-boostsecurity]

Looks like when comparing to Branch Protection, it is currently missing the Require review from Code Owners feature.
It's also, not clear if Require approval of the most recent reviewable push is actually covered by default or it's also missing that feature.

[patrick-knight]

Hey @fproulx-boostsecurity,

Those options are available when you select "Require a pull request before merging".

[bobby-lin]

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

[patrick-knight]

This experience is focused on branch and tag protections.

[jankudev]

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?

[patrick-knight]

@jankudev The new repository rules work along side the existing branch protections, so no existing functionality has been removed.

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?

Currently the transition will be manual as there is a not a full 1:1 migration path and but we are exploring opportunities to assist with the migration in the future.

It is possible that branch protections we're disabled via "the danger zone" and can be reenabled there as well:

[carlosjgp]

I've found a use case where the PR checks are not working

I get 422 error

{
	"3": {
		"_dirty": true,
		"_enabled": true,
		"_id": -43,
		"parameters": {
			"required_status_checks": null,
			"strict_required_status_checks_policy": true
		},
		"ruleType": "required_status_checks"
	}
}

[patrick-knight]

Once you finish selecting the checks hit the ➕ sign to finalize and save the ruleset.

[LyleDavis]

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.

[patrick-knight]

Would it be possible to introduce rules around how PRs are merged via these rulesets?

This is on our shortlist backlog of enhancement we want to make to rulesets, no commitments I can share on timelines but it is been a topic of conversation.

[MichaelJJ]

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

[patrick-knight]

Pull Requests are blocked, even though I am a repository admin, is this expected?

It's possible if there are rules defined at the organization also protecting the same branch but does not have bypass defined.

Is this supposed to be the same as the branch protection rule "Restrict who can push to matching branches"?

Yes, we simplified the naming which also made it applicable language for tag rulesets.

[MichaelJJ]

I'm an org admin, and there are no org rules setup at this time.

[patrick-knight]

That feels off, hard to say exactly via the community. Can you open an issue with support so we can get more details privately to help triage whats happening here.

[MichaelJJ]

Thanks, I filed a ticket (#2269430)

[mohitnvs2397]

Repository rule violations found * Cannot create ref due to create name restrictions. * Branch name must start with a matching pattern: ^feature/\d+-(.*)$. Actually (this what is popping when i try to create branch with matching pattern also). Iam setting rulesets in GitHub, even after setting up branch naming convention regex pattern in metadeta restriction. how should give branch name to create the given regex pattern. help me create branch name patterns, what should i give it and what and all i should enable in rulesets to work the pattern creation. You can have a look at the screenshot below. Kindly do help me out with this.

[patrick-knight]

Hi @mohitnvs2397,

The rules selected are behaving as defined. As selecting restrict creations blocks the creations of new branches. As far as the rule around branch naming patterns, there seem to be different configurations in the screenshot vs the text post so it's hard to say there. Is the goal to ensure all branches start with feature/

[0xCVH]

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?

[patrick-knight]

Rule from the org layer on-top of existing rulesets or branch protections. Effectively you get the most restrictive outcome. If at the org you only define 1 PR approval but at some reposts that is two or three, the repository levels wins. However, the repo would be allowed to have less than 1 approval since that is the org defined minimum. Hope that helps.

[patimen]

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

[patrick-knight]

We're not planning on that, but I am curious to learn more about this scenario when checks are required for only a small group.

[patimen]

Our immediate scenario is that some outside contributors (internal to our company) just aren't up for the rigor of, say, resolving all conversations or abiding by strict static analysis. But our core contributors would still like those requirements, and we can manage outsiders by reviews instead.
I could see it also in the reverse, where outside contributors are held to a higher standard, or specific people (say, people new to a project) need, say 2 approvals instead of just one for core contributors.

[iainlane]

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?

[OneCyrus]

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?

[kaankoken]

I am not able to add status check on rulesets.
The error is "Invalid rules: 'Required status checks'"
I tried both of my private & public repositories, and I could not add status-check

Edit: I checked via the developer option, and it gives a 422 status code. Also, sudo is true