rulesets/nixpkgs: introduce required status checks

[wolfgangwalther]

This enables the "Required Status Checks" feature for Nixpkgs' development branches.

At this stage, all nixpkgs committers can bypass the checks. See discussion in #130.

Notes:

• I intentionally left out python-updates and r-updates, which both have "no-delete" rules, but not "no-force-push". Status of those branches is discussed in nixpkgs branch protection rules: prevent creation of new branches! #118.
• The teams ID can be confirmed with: gh api /orgs/NixOS/teams/nixpkgs-committers.
• nixpkgs branch protection rules: require status checks to pass #130 also mentions a "allow reverts" step, but this can be done after enabling the ruleset, since all committers can bypass anyway.

cc @MattSturgeon

[MattSturgeon]

• Diff LGTM
• Committers team id verified via rest api

This directory contains JSON exports of branch protection rulesets for repositories in the NixOS org.

They are not managed automatically, but can easily be imported by org owners.
To propose changes to branch protection rules, you can open a Pull Request.

For a second, I thought there was some magic github org-repo that'd could declaratively manage repo settings...

[infinisil]

While I can't actually import this ruleset directly (gives an error), I can manually create it and then re-export it. Can I get another approval from an @NixOS/org owner for this? :)

@wolfgangwalther Thanks a lot for all this work, very appreciated!

[wolfgangwalther]

While I can't actually import this ruleset directly (gives an error)

Interesting, what's wrong with it, I wonder? I guess we will see after export ;)

[infinisil]

Applied!

[infinisil]

Btw the problem with the importing was just that the JSON list had an extra , at the end 😆

[mweinelt]

What prevents us from enabling merge queues now?

[infinisil]

We could probably try that, I have the option to enable this for the ruleset:

[infinisil]

These are also options, repo-wide:

[mweinelt]

Yes, auto-merge would make reviewing and merging async. That would be super helpful. And you can cancel until it is merged.

Actually, I care more for auto-merge than merge-queues. Merge queues would be an experiment, auto-merges should be fairly safe.

[wolfgangwalther]

re merge queues: before we can enable these, we need to split the ruleset etc. - we can't require them for the staging branches right now, because all our periodic merges need to bypass that etc.

re auto-merge: that's surely something we can try. we just need to consider that it won't wait for ofborg - it will only wait for eval and the other basic checks.

[MattSturgeon]

These are also options, repo-wide:

FYI "Auto Merge" can be enabled either per-repo or per-ruleset. Also, I believe requiring "Merge Queues" implicitly enables "Auto Merge" for that ruleset, but I could be wrong.

What prevents us from enabling merge queues now?

We also need to add the on: merge_group event to the PR workflow; or add a separate workflow that runs on: merge_group but also has a no PR failures job.

Although I'm also looking forward to Merge Queues, I'd personally like to see the Required Status Checks working well in production before we rush into requiring a queue.

EDIT: We'd also need to consider how the ruleset targets branches, because Merge Queues cannot be used on rulesets that target wildcard branch patterns. E.g. we could have a "base" ruleset that uses wildcards, alongside a separate "overlay" ruleset that requires merge queues on explicitly named branches.

[mweinelt]

This regressed our periodic merge CI.

https://github.com/NixOS/nixpkgs/actions/runs/16222366363/job/45805853015

[emilazy]

staging* branches should probably be omitted from these kinds of changes by default since the workflow is significantly different. (It would be nice to make the workflow less different, but the reality is that direct pushes to staging-next etc. are still common.)

[infinisil]

Staging is now not included anymore: #139

[wolfgangwalther]

As mentioned in #139, I think we should keep this on staging, but allow the nixpkgs-ci app to bypass this ruleset as well. We actually discussed this issue already in #130 (comment) - but I entirely missed that we need nixpkgs-ci to be a bypasser as well.