-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Disallow executable bit on .nix files #110
Comments
Yeah this would be a pretty good fit for such a check! In particular it would fit around here: Lines 170 to 176 in 0d26da8
I think for this case it might be fine to just add a simple additional check and error, but in theory this could break master when a PR introduces an executable file but already went through CI before this change. So whenever strictness of checks is increased, a ratchet check would be most ideal to prevent such situations. If you do want to go for the full ratchet check, you'd have to extend While this would be neat, no offense taken if you don't go for that, a non-ratchet check is fine too (and perhaps somebody from @NixOS/nixpkgs-vet would be interested in making it a ratchet one) :) |
Does it really break master though? A nix file with an executable bit falling through the cracks doesn't seem like the end of the world to me. I personally think it'd be wiser to spend our time doing other work instead of creating a ratchet that most likely will not happen and is also not a critical bug. I can always set a reminder to run I'll play around a bit and see what I can come up with (I'll be slow though). We can then always decide to do it completely differently if desired. |
Scenario:
The premise of the ratchet checks is to avoid such a situation, by checking the base branch against the PR branch, only ensuring that new instances of a bad pattern aren't introduced, not that there is no such pattern at all. Granted, it's hard to say exactly what the chance is of this occurring. The fact that there were like 10 executable files before makes be believe it's not too uncommon, but maybe not worth creating a ratchet check for. Ratchet checks become less useful the less instances of a problematic pattern there are, but it's hard to draw the line. At some point I would like to have the code in a state where it's just as easy to add a new ratchet check as it is to add a strict check. We're not there just yet, but what pattern works should become more obvious as more ratchet checks are implemented. Anyways, I'd be happy to get a PR even for the basic check as a start :) |
FWIW checking executable bit on current nixpkgs master (still?) returns nothing: find . -type f -name "*.nix" -executable -print |
@willbush They were removed somewhat recently, I guess nobody added any since: NixOS/nixpkgs#341771 |
@infinisil still think this should be a ratchet check? |
Not worth it for now imo, but hopefully at some point ratchet checks are as easy as non-ratchet ones :) |
I came across a nixpkgs PR that removes the executable bit from some .nix files. This can be prevented by a check in CI.
Would this project (nixpkgs-vet) be appropriate for adding such a check, or would it fit better in a standalone loose action?
If we decide where it should go I'd like to take a stab at it.
The text was updated successfully, but these errors were encountered: