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 GA!

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

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

[shyvum]

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

[shyvum]

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:

[shyvum]

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

[shyvum]

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

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

[kryptonite07]

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.

[juk0de]

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.

[wyardley]

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

[heaths]

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.

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

[isker]

If this comment is to be believed, a previous beta version of the rulesets feature allowed only certain actors to bypass approval requirements on PRs while still requiring them to make a PR in the first place, by breaking things down into two rulesets: one that requires PRs (no bypasses) and one that requires PRs to have approvals (bypasses configured for relevant actors).

This is exactly what we want, in order to allow apps to land automated PRs without review, while still requiring normal developers to get approvals. But I am unable to make this work today by granting myself bypass (via both a team I'm in and a repository role that I have). The second ruleset (with the approval rules + bypasses) does not allow bypassing required approvals. I am always faced with this message:

Disabling the second ruleset outright permits merging, which indicates that the rules in each ruleset are themselves correct. But of course disabling the second ruleset is equivalent to allowing everyone to bypass this requirement, which is not what we want.

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

@patrick-knight do you know if this regression is intended or not?

[usmonster]

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

[isker]

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

[isker]

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

[patrick-knight]

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

[isker]

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.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Groxx]

I'm struggling quite a bit to figure out how to put limitations on semver tags, which seems like it's probably an extremely common desire for open source code, because quite often tags == releases == high risk and not always revokable (e.g. with Go modules).

Currently I'm guessing that I should do something like this, with two rules:

1. "block all non-semver tags". Apply to all, exclude v[0-9].[0-9].[0-9] and
   v[0-9].[0-9].[0-9]-prerelease[0-9] and...., and disallow create/update/delete. (I do not want non-semver tags at all)
2. "semver must be write-only". Apply to ^ those patterns, disallow update/delete.

I'm not yet confident that works, because the fnmatch documentation seems rather poorly suited for this kind of goal, and there doesn't seem to be any reasonable way to check it without pushing a bunch of test-tags somewhere.

But assuming that works, it leads to rather annoying cases like:
What about when we graduate past v1.2.9 and get v1.2.10? Is the only option to add more exclude/include duplicates for v[0-9].[0-9].[0-9][0-9] and v[0-9].[0-9].[0-9][0-9]-prerelease[0-9]?
The same question applies for v1.10.1, v10.123.1234, etc: do I need to allow every possible combination of digit-lengths, each one in a different pattern, and also duplicate it between the two rulesets?

Is there a better way to do this? Could I request a semver-specific thing, since semver tags are incredibly common, well defined, often have major side effects, and are not particularly fnmatch-friendly?

[seanbudd]

The newest status check interface seems to be broken.
Trying to set status checks here with no material changes yields this error:

Invalid parameter required_status_checks: Invalid integration ids

It seems like we can not set up, remove, or add any checks. This is after resetting them all

[seanbudd]

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

[seanbudd]

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

[TWiStErRob]

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:

Changing the source to "Any" saves successfully AND protects the branch:

---

One thing that's worth adding (probably the reason for this breakage) is that there's a new section at the bottom:

[AbdelrhmanHamouda]

We are facing an unexpected behaviour (despite documented but it still doesn't make much sense) where a ruleset is setup to check commit messages format on specific branch and PR merge strategy of squash & merge, the ruleset is checking the commits in the branch instead of the actual squashed commit. This adds burden and friction with development teams and make it harder to cultivate good practices

[zachariahcox]

That's a great observation. We are aware of that issue and are working on some enhancements there -- stay tuned and thanks for the feedback!

[jakeatoms]

In our rulesets, we allow certain automation service accounts bypass the rules, but they must be in a GitHub team. Ideally, that team could be marked as secret, so that it's not accessible/visible nor can it be @'d. However, the bypass search field doesn't return any secret teams.

[patrick-knight]

That was an intentional decision to not support secret teams here. It would have lead to a situation where it would have not be possible for admins to know why code was merged if they couldn't see a secret team or its members.