Don't require status checks for staging

[infinisil]

See #134 (comment)

Already applied

Ping @wolfgangwalther @K900 @emilazy @mweinelt

[wolfgangwalther]

I think we should go a different direction: We should allow nixpkgs-ci (which handles those merges) to bypass, too - and keep the feature enabled for staging.

[wolfgangwalther]

Looking up the integration's type and ID etc. is tedious - it's probably simplest, if you just add the bypasser and then export, @infinisil.

[emilazy]

Note that periodic merges into staging and staging-next can and do break eval, which will block PRs even once fixed in the absence of a proper merge queue. That’s precisely the case where the bot would be bypassing a “failing status check” if one existed.

Please be careful here; the staging workflow is a pain already and increasing friction further will strain the limited resources we have for it. Tightening rules for staging is more okay than staging-next, though.

I’d recommend hopping into the Staging room on Matrix to discuss the workflows involved and the issues we often have with CI if you don’t want to be conservative about changes that apply to those branches.

[wolfgangwalther]

Note that periodic merges into staging and staging-next can and do break eval, which will block PRs even once fixed in the absence of a proper merge queue. That’s precisely the case where the bot would be bypassing a “failing status check” if one existed.

Well, that's precisely what I concluded in #130 (comment) as well - every committer needs to be able to bypass these checks for staging-* branches. We just forgot about the nixpkgs-ci app, that's all.

[wolfgangwalther]

Note that if the conclusion is you'd rather want to go disable this entirely for staging - you'd also need to do it for haskell-updates, because the periodic merges in there are still broken right now.

https://github.com/NixOS/nixpkgs/actions/runs/16223200416/job/45808887124

[infinisil]

Just to make it consistent for now I also disabled it for haskell-updates and pushed the update here.

[emilazy]

Well, that's precisely what I concluded in #130 (comment) as well - every committer needs to be able to bypass these checks for staging-* branches. We just forgot about the nixpkgs-ci app, that's all.

I thought that the bypass doesn’t work with git push. If that’s not the case, then it seems fine to me. But we’ll need to be more careful around disabling the bypass for those branches, of course.

[wolfgangwalther]

issues we often have with CI

If there are known issues for staging-work with CI, it'd be great if issues in nixpkgs could be created for them and the NixOS/nixpkgs-ci team pinged. We can only take care of what we know about.

[wolfgangwalther]

I thought that the bypass doesn’t work with git push. If that’s not the case, then it seems fine to me. But we’ll need to be more careful around disabling the bypass for those branches, of course.

No, it works in our favor, the other way around. Those git push will always bypass, you can't prevent that. So that's precisely what the periodic merge needs.

I don't think we will be able to disable the bypassing for staging branches ever, due to how we do the periodic merges. This would only be possible if we switched to a PR-based periodic merge approach - which I don't see. So once we want to force the status checks without bypassing, we will only do so for master/release.

[emilazy]

If there are known issues for staging-work with CI, it'd be great if issues in nixpkgs could be created for them and the NixOS/nixpkgs-ci team pinged. We can only take care of what we know about.

Historically reporting those issues hasn’t resulted in any action. But I am grateful for the fact that that has improved recently, of course.

I am not sure if there are currently outstanding GHA CI issues for our workflow other than this one, I have just gotten the impression that understanding of the workflow is generally not very widespread and that CI changes have often been made that apply to those branches without full consideration/understanding of it.

[wolfgangwalther]

I am not sure if there are currently outstanding GHA CI issues for our workflow other than this one

Let me be clear: I am also very open to new suggestions on how to improve the work on staging branches, make it easier, more efficient - you name it.

If we can build better tooling for an area as critical, but at the same time as understaffed as staging... I'm more than happy to help.

[emilazy]

I appreciate that :) I have some thoughts on this that I’ll have to try and find the time to write up in more detail, but I’ve opened NixOS/nixpkgs#424345 as a fairly trivial thing I think would be a nice improvement.

[infinisil]

As a quick-fix I'm leaving it disabled on staging/haskell-updates for now, will come back to this though, an exception for nixpkgs-ci sounds good

[infinisil]

@wolfgangwalther @emilazy I now instead added an exception for the nixpkgs-ci app and manually triggered a workflow run, confirming that it works: https://github.com/NixOS/nixpkgs/actions/runs/16331765731/job/46135780251

@NixOS/org I'll need another approval to merge this