-
Notifications
You must be signed in to change notification settings - Fork 27
rulesets/nixpkgs: disallow creation of new branches #132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rulesets/nixpkgs: disallow creation of new branches #132
Conversation
This disallows the creation of new branches in the nixpkgs repo with the following exceptions: - `backport-`, `revert-` and `wip-` branches can be created by anyone. - `nixos-` and `nixpkgs-` branches can be created by the channel updaters. - `release-` and `staging-` branches can be created by the release team. This does not affect any existing branches, which we can fade out over time instead.
|
The related branches have also been documented here: https://github.com/NixOS/nixpkgs/blob/master/ci/README.md#branch-classification. We marked "all other branches", which would be forbidden to be created by these branch protection rules here, as "deprecated". |
|
Did you think how new branches could still be created once this PR is merged? There might be some scenarios where maintainers need to create semi-long-lived branches, so they can be built on Hydra. Let's say a new Gnome release for example. When that happens, the maintainers need to know what process they need to use to get that branch created. |
|
The idea is to use the Where would you suggest would this best be documented? In |
infinisil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds good to me, but can we can approval from another @NixOS/org owner?
| "refs/heads/nixos-*", | ||
| "refs/heads/nixpkgs-*", | ||
| "refs/heads/release-*", | ||
| "refs/heads/revert-**", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be
| "refs/heads/revert-**", | |
| "refs/heads/revert-*", |
Or is there no difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a difference: ** will include /. Aka when you have a branch called revert-123456-feat/stuff, revert-* will not match, but revert-** will.
Since the revert- branches are auto-created from the PR number and the head branch of the PR, which was provided by a regular contributor, this can use the / format.
I'm OK with not allowing these for wip- and backport- prefixes, but for the above reason we must support them for revert-.
Edit: This is a moment where I miss the ability to add comments to .json...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a difference:
**will include/. Aka when you have a branch calledrevert-123456-feat/stuff,revert-*will not match, butrevert-**will.
That's what the docs tell me, at least: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax
But it's apparently not that easy, because @philiptaron just hit this when trying to revert a r-ryantm. The branch is called auto-update/re2 - and is blocked by our new rule.
I reproduced this in my fork as well. Regular branches work well, but those with / don't.
After applying parent commit
|
Applied! |
This disallows the creation of new branches in the nixpkgs repo with the following exceptions:
backport-,revert-andwip-branches can be created by anyone.nixos-andnixpkgs-branches can be created by the channel updaters.release-andstaging-branches can be created by the release team.This does not affect any existing branches, which we can fade out over time instead.
This is work towards #118, although I wouldn't close that issue with this, yet. There's more ideas in there, some of which I'd need to move to the nixpkgs repo's CI as well. But also the clarification of "development branches" for some other branch protection rules.