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.

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

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

ok

Noted

Hey @fproulx-boostsecurity,

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

This experience is focused on branch and tag protections.

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

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

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.

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?

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.

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.

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.

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

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/

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.

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.

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.

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

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

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.

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:

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

@patrick-knight any update here?

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.

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

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

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

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 ?

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

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

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

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

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

That would allow for requiring workflows per repo.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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?

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.

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

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.

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.

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.

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.

Same for me. It's very confusing. I'd suggest to either fix that check (to also consider rulesets) or get rid of the message.

Yes, after adding rulesets that apply to the default branch and are enabled, I'm still seeing the "You haven't protected any of your branches" message under "branch protection".

I've tried using the default branch setting, as well as explicitly setting the default branch name and still get the same result: the confusing "You haven't protected any of your branches". I appreciate rulesets may one day replace branch protection rules, but it's obviously confusing a lot of people. I've seen it enough and know the rulesets apply, but I admit I still find it concerning at first glance and makes me question whether everything is set up correctly.

This sounds exactly like the issue I've been having with the feature. I've reported it to GitHub Support (ticket #2829120), and from my conversation so far it sounds like the engineers working on it are receptive to this feedback about the expected behavior in this scenario. 🤞

(This repository does involve a merge queue (required in the first ruleset) but I temporarily disabled that specific rule and nothing about the situation changed, so this problem seems unrelated to merge queues.)

Just kidding? I tried removing the merge queue rule again and it worked this time:

I've gone back and forth with the merge queue rule enabled and disabled multiple times, it definitely seems like it's down to this. I must have just been mistaken when I first said this. So, it is just as @usmonster says on that issue.

Well, the merge queue is not optional for us.

Sorry for the ping again @patrick-knight, but it sounds like you were gone when I originally left this feedback.

Rules cannot be bypassed to enter the queue as of now, this is intentional.

Sure, so it's a feature request: I think it'd be ideal for rules/permissions to apply to merge queues in the same way that they apply to normal merges. I understand that merge queues are relatively new and this use case is relatively niche, but it did prove to be a sharp edge for us.

In the meantime, to enable "approval bypass" for automated PRs created by this app, we ended up crafting a Rube Goldberg machine of automated approvals (involving another app approving PRs opened by the first app - because PR authors cannot self-approve) that encodes the same logic we hoped rules would have in the first place.

Someone else experienced this on reddit: https://www.reddit.com/r/github/comments/1erv40q/error_adding_codeguru_security_scanner_as/

Ok I've discovered the root of the problem, trying to enable CodeQL checks

For anyone else reading this: we had to change the source from "Github advanced security" to "github actions". hopefully this actually works

This broke recently, it was working previously.

yields the error on save:

Invalid parameter required_status_checks: Invalid integration ids

we can try to work around the error and set "GitHub Actions" it saves:

but it's actually not workable, because on PRs I see this: