Some of the tests depended on the evaluation order chosen internally by
nix-eval-jobs, which will break when that order changes. In practice the order
is not guaranteed, and already not deterministic with multiple workers.
Change-Id: I2e85d096f4439a8075a6f4a08d31c0f16a6a6964
The retry added in 4c5efd4548 has never worked
properly, as releasing the pid the first time causes it to be -1 and thus
waiting for a random child on retry. While there is a good chance that this
really catches the crashed worker, this is by no means guaranteed, and it could
just as well have caught different restarting worker. Wait synchronously
instead. The worst possible outcome is a hang instead of an error message if
the worker manages to close its pipe but then fail to exit, which is not
supposed to happen in the first place.
Change-Id: I4e4c3f532ec15c3118f6f77821ab820a6a6a6964
Closes#987
The patch adds a flag `--no-instantiate` which only performs evaluation
without instantiating any derivations. Hence, GC root creation is also
skipped. To achieve that, Lix is also put in read-only mode and all
operations that require reading a derivation (e.g. constituents or
listing input derivations) are disabled fallback values are set.
This is a port of an upstream PR[1]. Given the divergence of the
codebases (different restructurings on both ends, no more CA derivations)
I decided to redo large portions from scratch instead of
cherry-picking the patches. Hence, the authorship.
Additionally the clean up of casts down to a local store are removed or
guarded behind an if, as done in the upstream PR.
[1] https://github.com/nix-community/nix-eval-jobs/pull/379
Co-authored-by: Jörg Thalheim <joerg@thalheim.io>
Change-Id: Ib84f44e7799bc5577fd2ee98912458f16ebeab81
Closes#703
The problem boils down to:
* A testcase with a segfaulting worker due to a stack overflow from the
evaluation.
* When the controller encounters that the pipes are down, the worker's
state is checked and a potential infrec is reported if it stopped with
SIGSEGV.
* However, in a few cases, the worker didn't exit yet, but only had closed
pipes (which is how the error is detected). In that case, a different
error message is printed breaking the test.
This bug handling only affects error cases, so this race doesn't happen
on normal shutdown. To mitigate the problem a bit, the controller will
wait for a second and re-check the state of the worker process then.
While this should make the error reporting for end-users a little more
reliable, it's still no guarantee for a non-racy test. Hence, the test
asserts against both cases now and it passes if either the infrec error
or the "worker still running, but pipes are closed" error is returned.
Change-Id: Ifdc7a05bc86b6aecd5d03118d3e3ffc9affe1c5e
Hydra used to support aggregate jobs that only succeeded when their
constituents succeed. This is still used by e.g. nixpkgs[1].
Prior art:
* https://git.lix.systems/lix-project/nix-eval-jobs/pulls/17: got ported
into the CppNix implementation[2]
* https://github.com/nix-community/nix-eval-jobs/pull/349: implements
glob expressions for constituents - something we needed at work. This
also restructures the code a bit which is what I re-used here. The
globbing is not part of this patch.
Essentially, the following things happen here (assuming `--constituents`
is set):
* Derivations with `_hydraAggregate = true;` are considered aggregates.
These are not written to stdout when received by a worker, but stored
until the end.
* Constituents can be drv paths or strings (that must be the `attr` of
another job). In that case, the derivation of the aggregate job is
rewritten so that it depends on the drv of the constituent job.
* At the very end the aggregate jobs are also written to stdout.
Additionally, this fixes one bug, the old `hydra-eval-jobs`
implementation had (and we actually hit at work):
Given the leaf jobs `packages.foo` & `packages.bar`, an aggregate job
`aggregate0` with
_hydraAggregate = true;
constituents = [ "packages.bar" "packages.foo" ];
and an aggregate job `aggregate1` with
constituents = [ "aggregate0" ];
then it may happen depending on the order of evaluation that `aggregate1`
depends on the old derivation of `aggregate0` (i.e. the one without
rewritten constituents) and doesn't depend on `packages.foo` and
`packages.bar` because it was rewritten before `aggregate0` was
rewritten.
This is done in here correctly, but topologically sorting the aggregate
jobs before rewriting those.
[1] https://github.com/NixOS/nixpkgs/blob/bba6b37c9d0898867a7d9c38a1b5b77efcfb07b9/nixos/release-combined.nix#L69
[2] https://github.com/nix-community/nix-eval-jobs/pull/340
Change-Id: I5baad5e57336b4985ef8595e903814de83eb01c1
There's an `aio.blockOn` missing to resolve the promise. Also added a
test to verify that the GC roots are created as expected.
Change-Id: I88816cc1161372674ded15374b13323f41846453
This exposes the `pytest` suite as a Nix build. Previously, this didn't
exist and upstream just runs this in GHA. As a result, the test was
actually broken since the assumptions about the directory structure have
changed.
To not require network access, the nixpkgs used by the Lix flake is
injected into the test. The evaluation will be done in a chroot store
since the `openStore` call would otherwise need write access to
/nix/store.
Change-Id: Ib4ff5f0319ce3aabb3b7243a076ea169e27e3533
We don't want any of this github integration stuff since it won't do
anything, flakes don't support subdirs properly and maintaining a second
flake is pointless and annoying, and then the rest is lix formatting
standards hitting n-e-j.
Yeet!
Change-Id: Ibcd3b0182d90f727562a92c215b6061c16502554
Alois Wohlschlager