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

Use nix-eval-jobs and delete hydra-eval-jobs #1421

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Ericson2314
Copy link
Member

nix-eval-jobs was forked from hydra-eval-jobs originally, for others to use. That's great! But maintaining two copies is no good. But we use that.

Original author is @delroth, for Lix's Hydra, thank you!

Draft because some tests fail. I am not sure why. Maybe there are fixes on the Lix branch that can be cherry-picked to fix? Not sure!

@Ericson2314 Ericson2314 marked this pull request as draft November 13, 2024 21:50
@Ericson2314 Ericson2314 mentioned this pull request Nov 13, 2024
"--flake", $flakeRef,
"--gc-roots-dir", getGCRootsDir,
"--max-jobs", 1);
@cmd = ("nix-eval-jobs", "--flake", $flakeRef . '#hydraJobs');
Copy link
Contributor

@zowoq zowoq Nov 13, 2024

Choose a reason for hiding this comment

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

Uses hydraJobs here and the original hydra-eval-jobs has hydraJobs and checks:

auto aHydraJobs = vOutputs->attrs()->get(state.symbols.create("hydraJobs"));
if (!aHydraJobs)
aHydraJobs = vOutputs->attrs()->get(state.symbols.create("checks"));
if (!aHydraJobs)
throw Error("flake '%s' does not provide any Hydra jobs or checks", flakeRef);

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah found more commits that are relevant.

Copy link
Contributor

@zowoq zowoq Nov 14, 2024

Choose a reason for hiding this comment

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

The Lix commits don't address this issue, they only have support for hydraJobs.

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 would be important to keep the checks supports

@Ericson2314
Copy link
Member Author

I left a comment on nix-community/nix-eval-jobs#330, I think that is causing the failure. CC @Mic92.

@Ericson2314
Copy link
Member Author

nix-community/nix-eval-jobs#336 this I thought would help but is not sufficient hmm

@Ericson2314
Copy link
Member Author

( STDERR )  job  1    {"attr":"caDependingOnCA","attrPath":["caDependingOnCA"],"error":"error: derivation 'caDependingOnCA' does not have valid outputs: error:\n              ⦠while evaluating the output path of a derivation\n                at <nix/derivation-internal.nix>:19:9:\n                  18|       value = commonAttrs // {\n                  19|         outPath = builtins.getAttr outputName strict;\n                    |         ^\n                  20|         drvPath = strict.drvPath;\n\n              error: path '/0rmq7bvk2raajd310spvd416f2jajrabcg6ar706gjbd6b8nmvks' is not in the Nix store"}
( STDERR )  job  1    {UNKNOWN}: asdfasdf at /home/jcericson/src/hydra/master/src/script/hydra-eval-jobset line 412. at /nix/store/m07199rzw9ja8v6ba75r4ak5iy92ps9i-hydra-perl-deps/lib/perl5/site_perl/5.38.2/Catalyst/Model/DBIC/Schema.pm line 526

ah nix-eval-jobs needs more changes.

@dasJ
Copy link
Member

dasJ commented Nov 14, 2024

A relevant thing to consider here is whether we want an official NixOS project to be dependant on a Nix Community project. As of now (afaik), the NixOS GitHub namespace is mostly self-contained. I see these solutions:

  • Close this PR
  • Migrate nix-eval-jobs to the NixOS namespace (or even nix repo?)
  • Just live with the fact

I personally prefer the latter two options over the first one since it would get rid of code duplication and remove a component from Hydra that only a few people are proficient in and that gets a lot less maintenance than nix-eval-jobs.

Maybe that's a question for the new SC?

@Mic92
Copy link
Member

Mic92 commented Nov 14, 2024

Happy to move the project to the NixOS org if I can keep maintaining it there. We would loose aarch64-linux builds because those runners are currently sponsored by namespace in nix-community. I can attach my buildbot-nix installation to this org to compensate.

@Mic92
Copy link
Member

Mic92 commented Nov 14, 2024

Maybe that's a question for the new SC?

That's more a technical question for the Hydra/Nix team, unless we feel to overwhelmed what to do and need to escalate.

@Ericson2314
Copy link
Member Author

Ericson2314 commented Nov 14, 2024

OK it builds now (CI should say so in a moment).

@Ericson2314
Copy link
Member Author

Keeping draft just until nix-community/nix-eval-jobs#337 is merged.

@Ericson2314 Ericson2314 marked this pull request as ready for review November 15, 2024 15:57
@Ericson2314
Copy link
Member Author

OK undrafting because we're back on nix-eval-jobs main.

@dasJ I am fine resolving the nix-community thing later, because Hydra is a funny project --- it's official because history and because hydra.nixos.org, not because it is up to the quality we generally expect for 3rd-party use.

Copy link
Contributor

@Mindavi Mindavi left a comment

Choose a reason for hiding this comment

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

The perl bits look generally ok to me but not my expertise. Maybe put somewhere a bit clearer that the constituents are not supported anymore. That's not used on hydra.nixos.org, right?

Copy link
Member

@dasJ dasJ left a comment

Choose a reason for hiding this comment

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

As stated before, I do find this move to be a good idea. Here are some things I noticed while reading the code

flake.nix Outdated
@@ -8,14 +8,20 @@
inputs.nix.inputs.nixpkgs.follows = "nixpkgs";
inputs.nix.inputs.libgit2.follows = "libgit2";

inputs.nix-eval-jobs.url = "github:nix-community/nix-eval-jobs";
Copy link
Member

Choose a reason for hiding this comment

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

Can we somehow get that rev into the footer in src/root/layout.tt? I'm thinking something like Hydra 1.0 (using nix-eval-jobs abcdef and nix-2.18)

"--flake", $flakeRef,
"--gc-roots-dir", getGCRootsDir,
"--max-jobs", 1);
@cmd = ("nix-eval-jobs", "--flake", $flakeRef . '#hydraJobs');
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 would be important to keep the checks supports

push @cmd, "--no-allow-import-from-derivation" if $config->{allow_import_from_derivation} // "true" ne "true";
push @cmd, ("--gc-roots-dir", getGCRootsDir);
push @cmd, ("--max-jobs", 1);
push @cmd, "--meta";
Copy link
Member

Choose a reason for hiding this comment

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

Wills there two parameters change anything relevant?

Copy link
Member Author

Choose a reason for hiding this comment

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

 $ git log -G --max-memory-size
commit 4b107e6ff36bd89958fba36e0fe0340903e7cd13
Author: Pierre Bourdon <[email protected]>
Date:   Mon Jul 22 23:16:29 2024 +0200

    hydra-eval-jobset: pass --workers and --max-memory-size to n-e-j

    Lost in the h-e-j -> n-e-j migration, causing evaluation to always be
    single threaded and limited to 4GiB RAM. Follow the config settings like
    h-e-j used to do (via C++ code).

commit 6f1d68bda483b2ed3b1c1f0a696e8fe300108853
Author: Eelco Dolstra <[email protected]>
Date:   Wed Feb 19 20:36:52 2020 +0100

    Revert "hydra-eval-jobs -> nix eval-hydra-jobs"

    This reverts commit 345512a6d0743eaac9d451833ecc1a71d12809c9.

commit 345512a6d0743eaac9d451833ecc1a71d12809c9
Author: Eelco Dolstra <[email protected]>
Date:   Sat Feb 15 00:03:58 2020 +0100

    hydra-eval-jobs -> nix eval-hydra-jobs

It's purpose seems to be to change a setting that hydra-eval-jobs was changing programmatically before.

src/script/hydra-eval-jobset Outdated Show resolved Hide resolved
print STDERR "$stderr";
if (defined $err) {
print STDERR "$err";
undef $err;
Copy link
Member

Choose a reason for hiding this comment

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

Not sure about the API, but is it a good idea to undef this? Maybe set it to an emtpy string instead? Feels like that would die horribly if the process decides to do stdout, then stderr, then stdout again. Not sure why it would, but better safe than sorry

Copy link
Member Author

@Ericson2314 Ericson2314 Nov 17, 2024

Choose a reason for hiding this comment

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

I think every loop it will define them if they need to exists. Perl is weird! Why can't they just return a tuple!

@@ -709,36 +744,20 @@ sub checkJobsetWrapped {
return;
}

die "Jobset contains a job with an empty name. Make sure the jobset evaluates to an attrset of jobs.\n"
Copy link
Member

Choose a reason for hiding this comment

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

Is this a relevant check? Kind of surprising to see it gone

src/script/hydra-eval-jobset Show resolved Hide resolved
@@ -8,14 +8,20 @@
inputs.nix.inputs.nixpkgs.follows = "nixpkgs";
inputs.nix.inputs.libgit2.follows = "libgit2";

inputs.nix-eval-jobs.url = "github:nix-community/nix-eval-jobs";
inputs.nix-eval-jobs.inputs.nixpkgs.follows = "nixpkgs";
Copy link
Member

Choose a reason for hiding this comment

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

Something I forgot in the last review: I think we should also force the nix version of hydra into the package, otherwise we might depend on 2 nix versions

Copy link
Contributor

Choose a reason for hiding this comment

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

That's actually a good one and could be a problem if hydra or nix-eval-jobs doesn't keep up with nix releases.

Copy link
Member

Choose a reason for hiding this comment

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

I can maintain release branches for different nix versions again if this is needed.

@Ericson2314
Copy link
Member Author

Thanks for this good review, both of you. In light of these things. I am going to try to flip the order: re-draft this, and get Mesonification done first.

@Ericson2314 Ericson2314 marked this pull request as draft November 17, 2024 21:24
@Ericson2314 Ericson2314 force-pushed the nix-eval-jobs branch 2 times, most recently from a3e3fe9 to d2227af Compare November 17, 2024 23:26
(cherry picked from commit 684cc50)
Ma27 and others added 6 commits November 25, 2024 11:08
nix-eval-jobs streams output, unlike hydra-eval-jobs. Now that we've
migrated, we can use this to:

1. Use less RAM by avoiding buffering a whole eval's worth of metadata
   into a Perl string and an array of JSON objects.
2. Make evals latency a bit lower by allowing the queue runner to start
   ingesting builds faster.

(cherry picked from commit b0e9b4b)
This partially reverts commit 370a4bf.

(cherry picked from commit cdfc5c81e8037d3e4818a3e459d0804b2c157ea9)
Lost in the h-e-j -> n-e-j migration, causing evaluation to always be
single threaded and limited to 4GiB RAM. Follow the config settings like
h-e-j used to do (via C++ code).

(cherry picked from commit 4b107e6)
@Ericson2314
Copy link
Member Author

@Ma27 any idea why the constituents GC test is failing?

@Mindavi
Copy link
Contributor

Mindavi commented Nov 25, 2024

I've seen (presumably) races in some tests, this could be one too. But may as well be a valid fail.

@Ericson2314
Copy link
Member Author

It happened very reliably for me in the dev shell.

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

Successfully merging this pull request may close these issues.

7 participants