These now depend on an external patch set; add them to the release tests
to ensure that the build doesn't break silently as new kernel updates
are merged.
This properly supports the `supportedSystems` and
`limitedSupportedSystems` arguments of `release-combined.nix`.
Previously, evaluation would fail if `x86_64-linux` was not part either
of those, since the tested job always referenced the `x86_64-linux`
nixos tests (which won't exist in an aarch64-only eval).
Since the hydra configuration for the jobset`trunk-combined` has both
`aarch64-linux` and `x86_64-linux` as supported systems, this will make
aarch64 be part of the tested job on that jobset.
It was added in PR #79786 (7a625e7) and then removed in commit 2de3caf
(apparently unintentionally as a rebase conflict).
_I think the ordering used by Eelco would sort the line this way._
The SLIM project is abandoned and their last release was in 2013.
Because of this it poses a security risk to systems, no one is working
on it or picked up maintenance. It also lacks compatibility with systemd
and logind sessions. For users, there liikely isn't anything like slim
that's as lightweight in terms of dependencies.
IPv6 container support broke a while ago and we didn't notice it. Making
them part of the (small) release test set should fix that. At this point
in time they should be granted the same amount of importance as the
legacy IP tests.
This is because it will not eval properly with `hydra-eval-jobs`.
```
$ ...hydra/result/bin/hydra-eval-jobs \
--arg nixpkgs '{ outPath = ./.; revCount = 123; shortRev = "4567"; }' \
-I "$PWD" \
nixos/release-combined.nix
```
It fails with:
```
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
```
This was previously removed in 74c4e30842.
This will allow hydra to build iso and sd images for aarch64-linux, and
share a common channel with the x86-based platforms.
Currently, when building NixOS from a git clone, Nix has to copy
the entire repo at >1GB into the store by default. That is not
necessary and causes a dumping large path message.
If you need the old behaviour for some reason, you will have to
specify it by passing the path to your repo explicitly as the
nixpkgs argument like this:
--arg nixpkgs '{outPath = ./.; revCount = 56789; shortRev = "gfedcba"; }'
The existing callSubTests seems to already have special-cased code to
allow enabling subtests on a single specific system by looking at the
`system` attribute in the test arguments. Replace it with a new version
similar to the callTestOnTheseSystems because:
- It's consistent with the existing functions for creating
system-specific tests (though admittedly, the callSubTests special
case for `system` predates them)
- This approach allows limiting to multiple system types, the previous
one inherently allows only one system type.
- This also fixes the problem that if you pass in e.g.
supportedSystems = [ "aarch64-linux" ], you end up with a
tests.chromium job that silently runs on x86_64-linux.
- Finally, this causes renames of the jobs like:
tests.chromium -> tests.chromium.x86_64-linux to be consistent with
the rest of the tests.
Currently, even if you pass supportedSystems = [ "aarch64-linux" ] you
end up with e.g. `nixos.tests.docker` which actually silently runs on
x86_64-linux. Using the new callTestOnTheseSystems fixes that.
As a side-effect, this also causes a rename of
`nixos.tests.docker` -> `nixos.tests.docker.x86_64-linux`, which is IMHO
a good thing since it's makes them consistent with the rest of the
tests.
Lately failing i686 tests like firefox have been blocking channel
releases. We're still building the tests for systems with limited
support but won't delay a channel release if they fail.
Arguably, breaking linux-latest should not block a release. Also, booting
the kernel + basic sanity checking is implicitly exercised by every other
vm test.
