Skip to content
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

Policy change: pushing to protected branches is now blocked #249117

Closed
zimbatm opened this issue Aug 14, 2023 · 15 comments
Closed

Policy change: pushing to protected branches is now blocked #249117

zimbatm opened this issue Aug 14, 2023 · 15 comments

Comments

@zimbatm
Copy link
Member

zimbatm commented Aug 14, 2023

Starting this week, we1 are enabling branch protection on Nixpkgs to require pull requests for all commits to the master and release-* branches. This will prevent the almost 200 Nixpkgs committers from pushing directly to those branches, which already almost never happens anyways.

Unless this causes major problems, we intend to keep this enabled permanently. Please use this issue to report any problems you encounter because of this.

What branches are affected?

The master and release-* branches that are consumed by Hydra.

What if I need to push?

Please contact the release managers as they will be added to the exception list.

In general, we expect that the PR workflow will be enough for the vast majority of cases.

Background

This change was originally proposed almost 3 years ago with closed RFC 79 when direct pushes were way more frequent at about 5%. Very recently a new attempt was started with RFC 156, for which @infinisil computed that nowadays only 0.05% of commits are pushed directly. The RFC was struggling to get enough shepherds, when @zimbatm rightly pointed out that such simple decisions shouldn't be blocked, following up with the proposal to just enable it and try it out.

Footnotes

  1. @zimbatm will enable it, with support by @infinisil

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/policy-change-pushing-to-protected-branches-is-now-blocked/31719/1

@zimbatm

This comment was marked as outdated.

@zimbatm zimbatm pinned this issue Aug 14, 2023
@infinisil
Copy link
Member

Note that releases should also work without direct pushes, which is being discussed in NixOS/release-wiki#70, so this exception should be removed in the future

infinisil added a commit to tweag/nixpkgs that referenced this issue Aug 14, 2023
We are trying out not allowing direct pushes anymore, so this is not necessary anymore, unless we later revert it again (unlikely): NixOS#249117
@FRidh

This comment was marked as resolved.

@infinisil

This comment was marked as resolved.

@infinisil
Copy link
Member

infinisil commented Aug 14, 2023

@Ma27 pointed out that it looks like PR's can't be merged anymore when a committer requested changes (though it seems like those reviews can be dismissed? Edit: Confirmed, can be dismissed), additionally auto-merge seems to be available now:
2023-08-14_19-15

It doesn't seem inherently bad, but I did not expect that to happen.

@FRidh
Copy link
Member

FRidh commented Aug 14, 2023

@Ma27 pointed out that it looks like PR's can't be merged anymore when a committer requested changes (though it seems like those reviews can be dismissed?), additionally auto-merge seems to be available now: (image)

It doesn't seem inherently bad, but I did not expect that to happen.

"Require approvals" can be disabled. And indeed, depending on the configuration, committers can also dismiss a review.

@infinisil
Copy link
Member

infinisil commented Aug 14, 2023

@FRidh I'm pretty sure that setting is not enabled. Indeed as an example, #249150 was merged 1 hour ago (when the setting was already in effect), and it was merged without any reviews.

The good thing is that dismissing reviews does allow merging again, even if it's your own PR. And even better: To dismiss reviews you have to give a reason, I tested this here: infinisil/github-test#2 (review)

@infinisil
Copy link
Member

Fyi, we do have the option to turn off allowing auto-merges, see here.

@infinisil
Copy link
Member

I think we should disable the auto-merge feature because it works only based on the reviews and completely ignores the OfBorg status. And until we have more solid CI we cannot also require CI checks to pass before merging.

@zimbatm
Copy link
Member Author

zimbatm commented Aug 15, 2023

I turned off auto-merges.

@rnhmjoj
Copy link
Contributor

rnhmjoj commented Aug 15, 2023

The RFC was struggling to get enough shepherds, when @zimbatm rightly pointed out that such simple decisions shouldn't be blocked, following up with the proposal to just enable it and try it out.

Meh. I don't oppose this policy, but I don't like how this decision sidesteps the RFC process.
Does this imply proposals can be tacitly approved if they don't get enough attention? It doesn't seem right.

@Ma27
Copy link
Member

Ma27 commented Aug 15, 2023

The good thing is that dismissing reviews does allow merging again, even if it's your own PR. And even better: To dismiss reviews you have to give a reason, I tested this here: infinisil/github-test#2 (review)

@infinisil for the record, I'm fine with that and I withdraw my skepticism :)
The problem I had with the previous behavior was that there was no way to override it (and from my experience almost every rule tends to have an exception ;-) ). I haven't checked it so far, but if it's possible to dismiss now while having to provide a reason for that seems good to me, thanks 👍

https://discourse.nixos.org/t/policy-change-pushing-to-protected-branches-is-now-blocked/31719/1

OK with this one being pinned globally, my other issue is also resolved, this provides reasonable visibility for each committer.

IIRC we haven't had notable config changes in the repo for a while and I'm not sure if there are follow-ups planned to this, but for the future I'd like to suggest to always communicate it via a globally pinned discourse topic (and perhaps even cc all of the committers in $github_issue).

@infinisil
Copy link
Member

Meh. I don't oppose this policy, but I don't like how this decision sidesteps the RFC process.
Does this imply proposals can be tacitly approved if they don't get enough attention? It doesn't seem right.

@rnhmjoj I know it looks a bit like we pulled a Flake again, but:

  • The change does not have any long-lasting API or user implications, it can be reverted at any point without problems
  • The change has a very low negative impact, only ~0.05% of commits were direct pushes
  • Meanwhile, the change has a significant positive impact, especially for security

Considering this, I don't think it's necessary to have an RFC for this, because it should be an uncontroversial change, and indeed, we haven't seen any good reason in the RFC to not do this.

But also a big argument is that going through an RFC for something so minor distracts people from more important problems to fix. Not having to maintain this RFC for months frees up time for me to e.g. focus on implementing accepted NixOS/rfcs#140, which is considerably more impactful.

@zimbatm
Copy link
Member Author

zimbatm commented Sep 6, 2023

Closing as this was up long enough

@zimbatm zimbatm closed this as completed Sep 6, 2023
@zimbatm zimbatm unpinned this issue Sep 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants