These take up 2 GiB every time anything in the minimal installer
changes, or up to 4 GiB per day. We already stopped building Amazon
images in 9426d90c67. Meaningful
installer changes are rare enough, and the couple of days it takes
for them to trickle down to the large channel acceptable enough,
that this is mostly a waste of space.
This should buy enough slack to build `stdenv` on `staging` without
contributing to cache size growth.
Eelco has made several early contributions to NixOS including writing
the samba module among other things, but is more or less inactive these
days.
By my brief inspection, he has not committed to the nixos/ tree since
releasing Nix 2.13 in early 2023 and merging a PR to networking tests
slightly before that. A lot of these tests/modules are actually
unmaintained in practice, so we should update the code to reflect the
practical reality so someone can consider picking them up.
Now, it's `nixos.tests.misc.default` and `nixos.tests.misc.lix` since
Lix introduction in #310194.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Let's test / on ZFS and /boot on ZFS in separate tests since the GRUB integration for ZFS seems to be not very well maintained.
If the test breaks in the future it's easier to figure out that ZFS on /boot is at fault and either fix the issue or disable the test.
The new test creates a ZFS pool where all features not compatible with GRUB2 are disabled. The dataset is then mounted on /boot and we check that the installer correctly generates a bootable configuration.
Try to use as many ZFS features as possible to verify that GRUB can handle them.
At the time of writing, an increased source of failure in our CI is related to i686-linux.
While I do wish to support 32 bits x86 system further, the reality is that we cannot
identify in our community maintainers for `i686-linux` that can provide continuous maintenance
for our i686-linux packages.
As a matter of fact, `i686-linux` is probably broken in nixpkgs, we decide to rip off the band-aid
and drop the support.
Next steps could involve to extract a core package set of nixpkgs / NixOS in an out-of-tree
repository to offer a simple 32 bits NixOS support with a cache or to find maintainers
who are willing to work on i686 support.
The current state is certainly very wrong - testing ZFS only on i686.
I suspect it was a typo (?) in commit 2de3caf011.
The current practical problem is that the test fails,
though in a part that looks cross-platform (which adds confusion):
https://hydra.nixos.org/build/239290208#tabs-buildsteps
This splits the tests into two: one where cups.socket is started
normally, the order with socket activation.
Why? It's almost impossible to follow the test with 4 different
machines printing at the same time. It should also be more efficient
because only two VMs at a time were needed anyway.
The ACME module has long been an important part of every nixos server
deployment and we should therefore make sure the tests are working as
expected before allowing a channel bump to happen.
Related: #197443
Sway is a Wayland compositor. It should have a smaller userbase than
Gnome and KDE but Sway plays an important role in the Wayland ecosystem
(it is e.g. maintained by Simon Ser who also maintains wlroots, Wayland,
and Weston (the reference compositor) and contributes to a lot of
important packages in the Wayland ecosystem). Sway also comes with much
fewer dependencies than large desktop environments.
This should make the Sway VM test an ideal choice for testing updates to
core packages (e.g. wayland, wayland-protocols, wlroots, libdrm, mesa,
and xwayland - I maintain all but XWayland in Nixpkgs) and test failures
should be much easier to debug.
The test is fairly new but so far all 18 Hydra builds on x86_64-linux
have succeeded [0]. I'm actively maintaining the test and can look into
build failures if I'm pinged.
[0]: https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.sway.x86_64-linux/all
This reverts commit 2dbd08dcbd.
I've fixed the regression in 8a7a8442c1 and the rest of my
refactorings/improvements shouldn't affect the stability of the test.
Chromium seems to run fine but the VM test fails and prints errors like:
machine # There are no windows in the stack
machine # Invalid window '%1'
machine # Usage: windowfocus [window=%1]
machine # --sync - only exit once the window has focus
This could be due to changes in Chromium's X11 code (or maybe some
changes for Ozone/X11). I'll investigate this but let's temporarily
remove the Chromium test from the tested jobset until I find a proper
solution/fix.
