Instead of uploading the outpaths as artifact, this uploads them via
cachix. Most of all, this makes CI less brittle, because Eval in PRs
will still be able to succeed, even if no workflow run for the push
event could be found on the target branch. It will just take longer.
This also makes moving Eval into the Merge Queue easier to do: When
downloading artifacts from a different run, these would always have to
match on the right event, too. By pulling from cachix, the same workflow
can support target branches with merge queue and without merge queue at
the same time. The latter would still use the push event, while the
former could use the merge_group event.
Last but not least, this should fix Eval on PRs targeting `wip-`
branches and any other branches that the push event doesn't trigger on.
These would never find an Eval result from the target branch and could
never show rebuilds accurately. Now these PRs should work at a slightly
higher runtime cost.
With the latest performance improvements, this only adds up to 1s, but
reduces complexity in managing pinned checkouts explicitly, especially
when we need *both* pinned checkouts in the next commit.
The concept of having a "minimum supported Nix version" doesn't work
anymore today, for the following reasons:
- With multiple forks / implementations of Nix available, their feature
sets and versions will differ. We'd need *multiple* minimum versions,
one for each implementation.
- Lix does not expose its real version. It only reports "2.18.3-lix",
even though its real version is in the 2.90+ range.
- A minimum version has the expectation that it could be *raised* in the
future. That's not possible with Lix, because Lix will always and
forever report the above version.
- A minimum version has the expectation that *all* versions bigger than
the minimum are supported. That was already quite a stretch when minver
was 2.3 and none of the Nix versions between 2.4 and 2.23 were packed
anymore. But it's impossible for us to test all these non-LTS versions
anyway: We don't have Nix 2.18, 2.19, 2.20, 2.21, 2.22, 2.23, 2.25, 2.26
and 2.27 available in Nixpkgs at the time of this writing.
With their policy around `builtins.nixVersion`, Lix forces our hand: We
need to replace minver.nix with a "feature detection" mechanism.
This PR introduces the first two features:
- The availability of `builtins.nixVersion`: If this is not available,
the version of Nix is so old, that we surely don't support it anymore.
- The value of `builtins.nixVersion` being greater or equal to 2.18.
Note, that this does **not** imply support for Nix 2.18. Instead,
explicitly supported versions of Lix and Nix are only these that we
actually test against.
If, eventually, we realize that the supported versions have advanced and
Nixpkgs has adopted a feature only available in newer versions, we will
have to add a feature check for this.
Put differently: The list of features in `minfeatures.nix` is not
expected to be complete. It's a list of known-to-be-bad conditions that
will cause problems when evaluating Nixpkgs. Their only purpose is to be
able to show a helpful error message. Some other versions might also not
be supported, but might fail with more subtle errors. That's just
reality and has always been the case previously as well.
Sandro Jäckel