We don't want to push out a channel update whenever this test fails,
because that might have unexpected and confused side effects and it
*really* means that stage 1 of our boot up is broken.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As @bobvanderlinden suggests in #13585:
"Looks like that cleans things up quite a bit! Just one aesthetics note,
the boot tests could now be renamed from boot.bootBiosCdrom to
boot.biosCdrom in nixos/tests/boot.nix:L33.
That makes them more consistent with the other tests."
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This makes it easier to test just a specific channel rather than to
force testing all builds down the users/testers throat. Especially this
makes it easier to test NixOS channel upgrades only against the Chromium
stable channel instead of just removing the beta/dev channels from the
tests entirely (as done in 69ec09f38aa1f1d37baec73ebdf9cf5f21050f94).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Should clean up a lot of these redundant lines for various sub-tests.
Note that the tests.boot* are now called tests.boot.boot*, but otherwise
all the test attribute names should stay the same.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
Cc: @wkennington
Cc: @bobvanderlinden
It serves as a regression test, because right now if you enable
networking.useNetworkd the default loopback interface doesn't get
assigned any IP addresses.
To be sure, I have bisected this and it has been introduced with the
update to systemd 228 in 1da87d4.
Only the "scripted" networking tests have to succeed in order to trigger
a channel update of nixos-unstable, so I'm leaving this test as broken
and we have to figure out next what's the *exact* reason for the
breakage.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Currently there are no tests that depend on the JDK. Since we don't
want a release with a broken JDK, make it an explicit dependency of
the "tested" jobs.
We want to avoid getting broken LUKS systems into the latest channel, so
let's ensure that the channel update won't happen if LUKS support is
broken again.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It has been removed by 71a197bc6e60c2c35687fc862cec9a0036a3877e.
I'm reintroducing the test mainly because it actually *is* useful,
because right now, machines with mdraid will not boot. In order to
prevent such things from happening in the future, we should *not* remove
this VM test again.
If it really goes back to failing randomly, we should really try to fix
it instead of removing it again.
Of course it fails right now because of the mdraid bump in 7719f7f.
Also, if you want to have additional info about the reasons, have a look
at the commit message of 666cf992f05d20c537da7f495afe3622023495d2.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It now strictly evaluates all remaining attributes, preventing
unevaluated thunks that cannot be garbage-collected. It's also applied
to all jobs in Nixpkgs' release.nix.
This reduces hydra-eval-jobs' memory consumption on the 14.12
release-combined jobset from 5.1 GB to 2.0 GB.
This test sometimes fails with
Kernel panic - not syncing: assertion "i && sym_get_cam_status(cp->cmd) == DID_SOFT_ERROR" failed: file "/tmp/nix-build-linux-3.14.32.drv-0/linux-3.14.32/drivers/scsi/sym53c8xx_2/sym_hipd.c", line 3399
after "sd 2:0:0:0: ABORT operation timed-out."
Since we don't care all that much about GRUB 1 anymore, don't make the
release depend on it.
http://hydra.nixos.org/build/19563197
This reverts commit 469f22d717e53c48d13a66ca862942e8098accc5, reversing
changes made to 0078bc5d8f87512104902eab00c8a44bef286067.
Conflicts:
nixos/modules/installer/tools/nixos-generate-config.pl
nixos/modules/system/boot/loader/grub/install-grub.pl
nixos/release.nix
nixos/tests/installer.nix
I tried to keep apparently-safe code in conflicts.
release.nix and release-combined.nix current hardcode the systems which
they are built for. This change introduces an argument to the
expressions called supportedSystems, which allows the builder to choose
which architectures he wants to build. By default, this uses the same
linux x86_64 and i686 architectures.
