This reverts commit de80d0544c.
Well, not a pure revert, but logically yes.
It's been so many years, and this version is almost 9 years old,
and now it won't even build anymore. Anyway, it shouldn't be a blocker.
https://hydra.nixos.org/build/292468814/nixlog/4/tail
Split tests up based on certain use cases:
- http01-builtin: Tests most functionality of the core module, such
as the systemd and hashing components, whilst utilising lego's built
in http01 resolution mechanis.
- dns01: Tests only that DNS01 renewal works as expected.
- nginx: Tests nginx compatability
- httpd: Tests httpd compatability
- caddy: Tests caddy compatability
Last year the initrd sshd broke due to an openssh update which looked
innocent enough (the change that broke the initrd was mentioned in the
changelog, but you'd be forgiven for not making the connection):
- https://github.com/NixOS/nixpkgs/pull/323753
- https://github.com/NixOS/nixpkgs/pull/323796
Hopefully this won't happen again, the initrd test has been added to
passthru.tests for openssh since:
https://github.com/NixOS/nixpkgs/pull/356190
However, it is probably best to also have such an issue block the
channel. The ssh initrd is probably almost exclusively used on
remote machines where it is really bad when the initrd sshd
doesn't come up since it is used to unlock an encrypted volume
or similar, so it'd be stuck in initrd indefinitely. Also,
for such systems it is usually very difficult to impossible
to easily choose a different generation to boot into via
the boot loader.
gitlab (or its test) commonly needs work to keep succeeding,
and currently I fail to see energy to keep it in sufficient shape
for aarch64 to remain a channel blocker. (x86_64 still will be)
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
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