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

top-level/release.nix: add patchShebangs test #46756

Merged
merged 1 commit into from Sep 17, 2018

Conversation

copumpkin
Copy link
Member

This is currently failing but nobody noticed!

Motivation for this change

The failure causes all sorts of subtle issues so best to catch it early and loudly.

@@ -77,6 +77,7 @@ let
jobs.tests.cc-wrapper-libcxx-39.x86_64-darwin
jobs.tests.stdenv-inputs.x86_64-darwin
jobs.tests.macOSSierraShared.x86_64-darwin
jobs.tests.patch-shebangs.x86_64-darwin
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I need to list these out? I was just following the pattern but it feels sort of redundant

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use [] ++ builtins.getAttrValues jobs.foo everywhere instead. However the unstable jobset would update if there's an evaluation error for one of the platforms, instead of making the job disappear.

This is currently failing but nobody noticed!
@LnL7
Copy link
Member

LnL7 commented Sep 16, 2018

I'm wondering if we should add these to a separate combined job and add only that one to unstable, etc. channel jobs.

@copumpkin
Copy link
Member Author

I think I'd be up for that but am not entirely clear on what you mean. Can you elaborate or push a change to my branch?

let
bad-shebang = stdenv.mkDerivation {
name = "bad-shebang";
unpackPhase = ":";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to do dontUnpack instead of this kind of weird trick.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh is that new?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No that's not a thing AFAIK, this is a pretty common approach to skip unpacking and it's better than setting phases directly. But we have dont* variants of most other phases, it would make sense to add it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I knew of the other do* and dont*s, but I thought there was none for unpack.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lose your unpack phase with this one weird trick. Maintainers hate it!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's what I was thinking too :D

@Ericson2314
Copy link
Member

Yeah let's please do this!! It will greatly assist Matt and I with any further experiments too :).

@copumpkin copumpkin merged commit bb65065 into NixOS:staging Sep 17, 2018
@copumpkin
Copy link
Member Author

@matthewbauer pretty sure this test will fail on current staging, FYI, even with your change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants