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. There are now org customer roles which include a role for rulesets.
• No merge queue support at the moment Now in beta!

[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/[email protected]
        with:
          github_token: ${{ steps.generate_token.outputs.token }}
          branch: ${{ env.BRANCH }}

[NushaMBZ]

ok

[samsonmobisa]

Noted

[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]

So you are looking to support a group of users above folks with the triage role to have permissions to merge PRs? Could you help me understand the distinction between those sets of users? And where meeting minimum reviews are not sufficient here?

[Thunderforge]

So you are looking to support a group of users above folks with the triage role to have permissions to merge PRs? Could you help me understand the distinction between those sets of users?

@patrick-knight No, the Triage role does not work here because that applies to the entire repo. In contrast, Branch Protections & Rules apply to certain branches. We want people to have Write permissions in general, but not for certain branches (e.g. release/**). The Branch Protections allows for this behavior.

And where meeting minimum reviews are not sufficient here?

We want 2 approvers (any devs on the team), but the team lead is the only one we want to allow to merge to that particular branch. If we just rely on 2 approvers to block merging, we could reach the minimum and then a dev could merge, without the lead to be involved.

Again, the Branch Protections "Restrict who can push to matching branches" allowed this behavior, but Rules does not.

[usmonster]

Hi, just to add another use case to this thread:

• We're using Atlantis to help us merge PRs that modify Terraform state
• Before Atlantis can apply Terraform changes, it checks the merge state status of the PR and fails fast if the API says it's not mergable
• There is a mismatch in API behavior when the target branch of the PR is protected by the allowlist of a "legacy" Restrict who can push to matching branches branch protection vs. when the target branch is protected by the equivalent ruleset (i.e. Restrict updates + bypass list); you can try this at home:

$ gh api /repos/$ORG/$REPO_WITH_BRANCH_PROTECTION/pulls/1234 --jq .mergeable_state
clean
$ gh api /repos/$ORG/$REPO_WITH_RULESET/pulls/5678 --jq .mergeable_state
blocked

• The end result is that Atlantis doesn't know that it can merge even when it's in the bypass list, which breaks it completely on repos that use this ruleset.

I plan to open opened an issue about this on Atlantis's side, but I'm more convinced that there's work to be done on the GitHub side (GitHub support ticket #2512370). I'm not even sure what a good workaround would be without a way to know via API whether the caller can bypass restrictions on a blocked PR. It might require a new Merge State Status (e.g. BLOCKED_BYPASSABLE?) and/or some other dedicated metadata on the PR to indicate which rules would be bypassed by merging.

Thanks!

Edit: I just noticed this thread from September is about the same issue and includes an acknowledgement from @patrick-knight.

[elizabethsjudd]

I'm testing out repository rulesets for the first time to reduce our branch protections and I'm running into the same issue mentioned above where the ruleset setup of using Restrict updates does not create the same experience as the Restrict who can push to matching branches feature. This is critical for our InnerSourced project that everyone has write access has to be able to create a PR to create changes to our protected branch but we only want select people to be able to merge the PR. I don't want those people to also be able to bypass other PR requirements though.

[AdrianSchneider]

+1 really need a way to express the Restrict who can push to matching branches branch protection rule as a repository ruleset. We lock certain branches to specific roles and don't want to trigger a compliance exception every time they merge.

Any updates here?

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

[ShivamGoyal1899]

@patrick-knight can you look at this? we are also facing the same.

[ShivamGoyal1899]

bump @patrick-knight

[patrick-knight]

Hey y'all thanks for sharing feedback here. This post has gotten pretty big so on occasions I miss some replies and threads 😬

At the moment we don't have any plans for supporting this outside of bypassing the rule.

[adambiggs]

Seems like this rule is kind of broken currently... The first time anyone bypasses the rule, it seems that every other commit after that also needs to be bypassed.

We're migrating all our repos to a monorepo, and we want to enforce linear history for regular day-to-day work. But would like to create a merge commit using --allow-unrelated-histories for the initial commit when an external repo's history is merged into the monorepo.

I assumed the rule was only enforced for newly added commits, not the entire branch history going back to the beginning of time.

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

[patrick-knight]

The upcoming release will allow you to create a merge queue configuration inside rulesets inclusive of bypass.

Today you'd need to a repo admin or have the custom role to bypass rules to skip the merge queue defined in the old branch protection rules.

We're wrapping up a few last minute changes and should be out in a public beta pretty soon here.

Sneak peek:

[ShivamGoyal1899]

looks good, by when would we be able to see this on enterprise cloud?

[ShivamGoyal1899]

@patrick-knight any update here?

[patrick-knight]

We're aiming for mid-next week. There were a few things to wrap up on rule insights for queued PRs that took a bit longer than planned.

[patrick-knight]

This is now in public beta!
https://github.blog/changelog/2024-02-27-repository-rules-configure-merge-queue-rule-public-beta

[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

[kaankoken]

@patrick-knight Okay thanks, but it is super confusing. I think should be parallel what we used to use in branches.

[patrick-knight]

Thanks for the feedback we're planing future enhancements here to make that clearer.

[lsantosthoughtworks]

Hi @kaankoken How did you manage to type and select a rule (status check) on the "Required status check to pass before merging" field ?
I'm trying to make it from the organization settings when typing but nothing comes up at all.

Would you have any direction based on your experience ?

[patrick-knight]

@lsantosthoughtworks Org checks will only display apps that are installed at the organization level. These apps must be installed with the checks:write and statuses:write permissions. As far as the check names themselves we do not catalog them at the org level, but all you to type in the name of the check you require.

[patrick-knight]

Following up to share this ➕ has been removed and a new interface is rolling out.

[kaankoken]

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:

• I removed all branches rules from branches.
• I have created a rule for my beta branch from Rulesets and applied following

1. Enforcement status: Active
2. Bypass list: App that I created for creating automated PR's
3. Target Branches: beta
4. Branch protections: Restrict creations, Restrict deletions, Require linear history, Require a pull request before merging, Require status checks to pass before merging, Require branches to be up to date before merging & 5 status check, Block force pushes

Still I could not bypass it

[patrick-knight]

😬 Sorry I missed replying here. If you use a team/role does the bypass work as expected? If so it might be additional configuration/permissions on the app.

[unicornware]

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]

Not at the moment. We are investigating bringing an actions workflow rule to repo rulesets.

[unicornware]

would that allow team plan users to define org-wide required workflows?

[patrick-knight]

That would allow for requiring workflows per repo.

[alambike]

Hi all,

I think this has not been mentioned in the discussion thread, our problem is that we have a growing list of GitHub apps that need to bypass certain restrictions implemented as rulesets, for example the requirement to require pull request approvals to merge.

We are establishing the restrictions at the repository level, not the organization.

The question that arises is whether we need to define these GitHub apps explicitly in the bypass list, or if, on the contrary, with some permissions assigned to them, these GitHub apps would fall into some of these groups:

From the tests we have been able to do, the Repository Admin role group does not seem to take effect, even though the GitHub app has administration permissions on the org repositories, but the Organization Admin role does seem to take effect.

In summary, is there a way to identify all the GitHub apps that have administration permissions on a repository (or on the Organization) using one of the mentioned groups?

Thanks in advance

[patrick-knight]

Not currently. Roles and Teams are limited to user accounts for the time being.

Out of curiosity how many apps are you talking about here?

[alambike]

Thanks for your response @patrick-knight , currently we have 9 GitHub apps that provision changes in the org repositories (really there are 3 GitHub Apps, but we need to have them redundant to avoid issues with the rate limit, and this number probably will be increased, as more repositories are migrated to GitHub).

In any case, we have been able to verify that these GitHub apps can bypass the rules configured in the repository rulesets, when merging pull request, if they have the permission of "Administration - Read & write" in the organization (and the bypass rule to Organization admin is set in the rulesets):

I'm worried that in your comment you indicate that it shouldn't work, since then we have to go back to the previous idea of adding all that list of Github Apps to each ruleset that should be able to be bypassed. As I indicated, right now it is working for us by assigning that permission to these Github apps 🤔 .

[patrick-knight]

Ahh sorry I should be more clear here. The containers of "Roles" and "Teams" can only be comprised of user accounts and do not support Apps. So there is not a way to say this group of apps and have that be present in the bypass list.

[alambike]

Sorry for insisting @patrick-knight , but I don't think I have explained myself correctly. Currently we are able to bypass a ruleset by giving "Administration read&write permissions" over the organization to a GitHub app, and adding the "Organization Admin role" to the bypass list. Isn't this the expected behavior?
​

[vibro]

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:

1. If the daily PR does not have a ticket in the title, the merge commit from the PR fails the ruleset because the metadata is missing. The daily PR usually does not have a ticket associated, as it's an automated process.
2. When a user goes to resolve a merge conflict in their own PR via the Github UI, the resulting merge commit fails because there is no opportunity to add a ticket to the commit message. They have to rebase and force push from their own machine instead.

We're transitioning from Bitbucket, which allowed these sorts of requirements but skipped checking merge commits.

[bewuethr]

We're running into similar issues, but for the daily automated PR, if that's created by a specific bot user, you could exempt that user from the rule?

[WoodyWoodsta]

The ruleset editor has to be the most painful area of the Github UI (perhaps level with PR review 😁). I'm not sure if these have been mentioned before, but I'll collect my thoughts here anyway. Hopefully they can help with refining the editor in the future:

1. Default to "Active". If I'm creating a ruleset, it's pretty likely that it's because I want it to be active from the time I save the ruleset. I cannot understand why the "default" is to have it disabled, requiring us to manually enable it.
2. The required status checks box:
   1. No fuzzy searching. Not even case insensitive searching:
   2. Checkbox and "+" button required. This is pretty useless UX. I'm not sure why I need to both check the box and click the "+" button
   3. Show me all possible checks without any search input. I cannot understand why I need to specifically search for a check in order to select it. Without fuzzy searching, this experience is even worse.

[patrick-knight]

The ruleset editor has to be the most painful area of the Github UI

😞 I appreciate the direct feedback. We have a lot of interactions patterns on this page, and we are maintaining a backlog item of items to improve the experience. It is a very information and decision dense area of the product but we're always game for feedback to improve the usability.

1. This came from feedback one branch protections where a lot of folks didn't realize the immediacy of their actions and we saw from a number of interview and feedback sessions completing a ruleset took a bit of time and might be interrupted. And not having them default to active so gave folks the freedom to save in a partially completed state and come back to it. As we build understanding and confidence for folks in the feature it is an area for us to re-evaluate down the line.

2. 💯 We are going to be shipping an update to status checks soon that should help with points one and two: https://github.com/orgs/community/discussions/61107#discussioncomment-7449627
   On the last point frankly we don't easily have a way to that effectively for everyone as some customers have dozens to hundreds of checks.

[WoodyWoodsta]

Thanks @patrick-knight. Glad to hear these things are being worked on. I think similarly to the PR review page, rule editing could be visited on a high frequency when setting up or updating rulesets across 100+ repos, so these sorts of things matter.

where a lot of folks didn't realize the immediacy of their actions

Personally, I've not realised on a number of occasions that my rule was created but not enabled. In this situation, enforcing rules (and therefore providing security) should be the default as accidentally leaving a rule disabled could result in something irreversible.

We are going to be shipping an update to status checks soon that should help with points one and two

Fantastic

On the last point frankly we don't easily have a way to that effectively for everyone

I'm unsure why, because in the branch protection rules, we have the fuzzy (or at least wider) search capability:

I understand that underlying architecture might have changed, but we know it's achievable at least at the repo level.

[patrick-knight]

Fuzzy search yes, that is improving. But specifically listing all check is hard we give you a limited list of checks that are active over a 7-day window. And even if the backend worked differently showing a large list in that UI element has other challenges. So we're trying to find the right mix of usability vs technical limitations.

[patrick-knight]

To follow up we did start introducing a new experience for adding checks to rulesets and would be curious to hear if it's improved at all for you. No more needing to remember to hit the ➕ to add a check.

[WoodyWoodsta]

Hey @patrick-knight, thank you for keeping us updated - small improvement but it's still so clunky:

We now have:

• 2 instances of 3 consecutive, repeated, graphic/text indication something will be added (red boxes)
• As above, why "Add" is in the check title I have no idea - it's not the check title so I was pretty confused as to the actual check title/name
• A checkbox, which doesn't actually reflect whether it has been added (this only happens later) (if a form has checkboxes and no submit/save button, the user expects the checkbox to reflect the committed state)
• Why is there "Any source" under "Suggestions" when the existing checks do have a source, and when added to the main list do have a source?
• "Select type" - what type? I didn't know checks had a type?
• The only way to add from the list now is to blur the menu. Commit on blur should be in addition to something more concrete like a button "Close/complete"

Hopefully I'm not coming across too critical but I'm amazed at how this has become so overly complex for something which is fairly simple from the customer's perspective.

[bewuethr]

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

• When trying to merge a PR with a non-conforming title, it's rejected, like this:

  

• Titles of the individual commits in the PR don't matter

• The PR title matters only as far as it might be the default merge commit title, depending on the setting for the format of the default squash commit message (though see bonus wish at the end)

• This combination of PR title and commit titles meets the requirements:

  • PR title "[ABC-123] Add the feature"
  • Commit titles "Add one part", "Add another part"

Observed behaviour

• As long as any commit in the PR doesn't match the regex, merging is blocked; commit messages have to be updated via amending or rebasing
• The PR title doesn't matter at all
• Once all commit messages conform, the merge can still be blocked if the merge commit title doesn't conform
• This combination of PR title and commit titles meets the requirements:
  • PR title "Add the feature" (no ticket number!)
  • Commit titles "[ABC-123] Add one part", "[ABC-123] Add another part" (ticket number required on each!)

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

• enforce only when merging the PR
• bonus: a rule that enforces PR titles to follow the same rule

[zachariahcox]

I totally agree with this. The blocker at the moment is that we need a rule to require a certain merge strategy.
Enforcing such a thing generally can get pretty tricky. There are a number of teams out there that use PRs but rely on creating their own merge commits to close those PRs (they don't click the merge button). Teams usually do this to ensure that the merge commit itself is signed with their preferred key, not the gh key.
We are actively thinking about ways to improve this!

[poonesh]

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 Waiting for workflow to run. Setting the required repository ruleset back to evaluation mode fixes this issue. The first required ruleset succeeds however.

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?

[patrick-knight]

Looks there was an issue that had a fix release yesterday:
https://github.com/orgs/community/discussions/69595#discussioncomment-7592856

If you're still seeing this please reach out directly to support!

[audunsolemdal]

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

• requires pull request towards main branch
• requires the build of my source code to pass
• if relevant - integration tests, codeql check pass

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 if steps on jobs and steps, but it is sub-optimal as a lot of irrelevant workflows are triggered. Path filtering is preferred.

I also tried using Require deployments to succeed . This works, but it seems the deployment always needs to be latest version deployed. If having several pull requests open which deploy to the same environment, you will need to retrigger the "deplyoment" - which in this case is as simple as a dotnet publish succeeding

Essentially I would like more flexibility in specifying required workflows. The implementation could be as simple as status checks supporting operators such as OR AND in my case, although more advanced scenarios would require more.

[patrick-knight]

Thanks for sharing, this is common feedback we've heard and an area we've talked about more with the introduction of the org-level actions workflow rule.

[AlekSi]

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

Enforcing a linear commit history prevents collaborators from pushing merge commits to the targeted branches or tags.

I understand the part about pushing commits to a branch, but what does "pushing commits to tags" even mean?

[guspan-tanadi]

come across through discussions.

Hi, commits related to tags can be found in the tags commits list.

Just as when one push a commit to main branch, also are able commit to v1.15.0 tags.

[AlekSi]

Hi, commits related to tags can be found in the tags commits list.

Those are commits leading to that tagged commit. Just like https://github.com/FerretDB/FerretDB/commits/main shows a list of commits leading to the current HEAD of the main branch.

But that's not the same as "pushing commits to (something)". Pushing commits to a branch moves the HEAD of that branch. Pushing commits to tag… is just not a thing. The description in the documentation is just not correct.

[forever425000]

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?

[picturedesk]

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:

• Enforcement status: Active
• Bypass list: renovate-approve, renovate-approve-2 (Apps)
• Target Branches: main
• Branch protections: Restrict deletions, Require a pull request before merging (1 Approval, Require Review from Code Owner, Require conversation resolution before merging), Require status checks to pass (3 Checks), Block force pushes

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?

[stasostrovskyi]

It's not approver who needs to be on bypass list, but the actor who is trying to merge the PR. In this case, it would be renovate itself. Note that GitHub auto-merge will still not work (not exactly sure why), but next run of renovate will be able to merge, if you have renovate auto-merge enabled

[picturedesk]

You are absolutely right @stasostrovskyi . Thank you for clarifying. I was trying to allow bypass all renovate Apps, but it didn't work. So, I will wait until the next renovate run/pr, let's see.

[samsonmobisa]

You need to ensure that Code Owners are assigned to relevant files, and confirm that the specified Renovate Approvers have the necessary permissions. Check if any required status checks are failing, as this can prevent auto-merging. Additionally, review the Renovate configuration and consider reaching out to the community or support for specific guidance on any limitations or issues you're facing.

[picturedesk]

After added "only" Renovate App to the Bypass List and waiting for the next re-run of renovate it worked. Thanks @stasostrovskyi

[alambike]

Hello everyone!

I've been checking but I can't find any related comments.

Is there any reason why named users cannot be added to the bypass list, like we can do from branch protections? Is this something that is planned to be added to the rules feature, or is this use case not going to be allowed?

We have several service users (not GitHub apps) who need to bypass the pull request protections, but we see that it is not possible to add them nominally, without adding them to a group or role in the repository.

Thanks!

[patrick-knight]

That was a decision we intentionally made as we often heard the struggles folks had managing access for single actors and would often forget about it or struggle keeping configs in sync. So in rulesets we have limited the bypass list to just roles, team and apps.

[ffried]

@patrick-knight I support that decision given that we had the same problem and are switching to teams for managing access. However, we have external collaborators in some of our repositories and those cannot be added to teams. I cannot use a role for them either, because we have teams that all have the same role, but different rules.
Any suggestions?

[alambike]

In our use case, we have teams that have a service user (per team) to perform certain automated actions on their repositories, and they need their service user to be in the bypass list of certain rulesets that are applied globally on the organization.

Currently, with branch protections they could exclude their service user, but now they need to register a team to include this service user, which generates some bureaucracy by having to use an internal tool to manage their teams.

In any case, if it is the recommended solution, we will go with it.

Thank you.

[jnewland]

Organization rules do not currently support “Require deployments to succeed before merging”

I just ran into some trouble trying to enable the functionality I found documented at the linked URL. Can you describe the status of the known issue? The UI seems to lead me to believe that this works but once enabled I can't add any PRs to the queue. Once the UI has updated to show that requirements have been satisfied, clicking 'Merge when ready' returns an error complaining that the PR is in a clean status for some reason.

[patrick-knight]

The note is about not have support for them within organization rulesets. There are some limits today on how deployments are scoped which do give us a way to provide that behavior.

It sounds like you ran into an issue with deployments for a single repo, correct?

[jnewland]

Yes. Enabling “Require deployments to succeed before merging” led to reproducible errors attempting to merge PRs on a single repo. Once the UI has updated to show that requirements have been satisfied, clicking 'Merge when ready' returns an error complaining that the PR is in a clean status for some reason.

[patrick-knight]

Does the same issue occur if you require the while use the older branch protection rules?

[ViacheslavKudinov]

Hi,
it will be great to have "Rule insights" under the usual repository "Insights" and visible not only for "Admins"/etc privileged roles.
In that case, developers can learn based on their experience when the Rule is in the "Evaluate" state.

For us, it is relevant for the use case when we evaluate Metadata restrictions to get "Conventional commits", but we start with not enforcing the developers to follow.

Some kind of grace period when we can teach them that they make mistakes and need to improve.

[patrick-knight]

Thanks for the feedback there @ViacheslavKudinov, i's helpful to hear about additional ways folks would use that data. We had originally envisioned insight as a way for administrator to validate rules where working as expected. So today all the permission are built around that assumption, but as we explore additional data that relevant for developers in a repo this will be a good to think about.

[svanherk]

We're trying to move a number of our repos from branch protection rules to rulesets, but it's causing confusion when people go to /settings/branches and see a big warning saying "You haven't protected any of your branches":

If rulesets is supposed to replace branch protection rules, I'd expect some kind of messaging like "You don't have any branch protection rules in place, but you do have rulesets set up. See them here..."
Or even messaging trying to encourage people to go make a ruleset, rather than a branch protection rule.

(Apologies if this was already mentioned somewhere above, I didn't find it through quick searching.)

[patrick-knight]

In the danger zone of repos there is the ability for admins to disable branch protection rules.

And all the "you haven't protected any of your branches" messages should only apply if there are no rulesets and the create flow also prompts you to use rulesets now as well if you are on the branch protection page.

We have not officially replaced branch protections but are obviously heavily implying it right now. That will change over time as we encourage the transition in new ways over time.

[svanherk]

Ah ok that's good to know, we can look at disabling branch protection rules for repos we've moved over.

And all the "you haven't protected any of your branches" messages should only apply if there are no rulesets and the create flow also prompts you to use rulesets now as well if you are on the branch protection page.

This isn't happening for me, unless I'm misunderstanding. I still see the message above even if the repo has rulesets setup and enabled, and if I press that "Add branch protection rule" button it takes me to the regular create page and doesn't mention rulesets.

[grahame-student]

I've got this scenario that I'm scratching my head over

• private template repo intended to allow consistent repo instantiation
• Required workflow (super-linter slim) that ensures that all default branches in all repos starting with specific pattern within our org have a base-line quality level

As the org owner I'm able to successfully create a new repo from the template. Rule insights indicate that a bypass has been applied against the required workflow.

My devs are unable to create a new repo from the template and we see the following in the rule insights

I've tried creating a role, with a small number of devs, and adding the role to the bypass list of the failing rule. The devs within that role are still unable to create a new repo from the template.
I've had a look at the available permissions and added the bypass branch protections permissions to the role, again with no success.

This feels like something that should be possible, but I'm not seeing anything else that I'm missing.

[nbentfeld]

I would like to be able to add custom activity types that trigger ruleset workflows.

The current behaviour is not sufficient for my use case.

https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#supported-event-triggers

Any filters you specify for the supported events are ignored - for example, branches, branches-ignore, paths, types and so on. The workflow is only triggered, and is always triggered, by the default activity types of the supported events.

I have a workflow that checks if auto-merge is enabled and if the auto-merge commit message follows the conventional commits specification.
I want to use this workflow for all of our organization's repositories by referencing it in the ruleset.
With the current behaviour, a contributor must re-run the workflow manually to pass the checks. It would be great if the ruleset workflows could support custom activity types, in my case auto_merge_enabled and auto_merge_disabled.