| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
That way we have everything regarding the vuizvui testing system in one
module instead of two.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Unfortunately, we went into trouble and the Hydra machine not only
consumed lots of ram during evaluation but it also triggered a bunch of
evaluation errors because the available tests were strictly evaluated.
Using attribute paths consisting of plain strings doesn't have the same
problem, even though they look a bit uglier.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
So my gut feeling in 90c080e was't wrong after all, so we need to create
jobs for all the tests the machines include.
In order to make this easier, we're going to re-use the collection of
all test attributes from release.nix so putting it in lib/ makes sense.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is going to be used in modules or configurations to include tests
specific to the module, for example let's say you have a foo.nix module
that defines a foo service and you have a test named "foo" in the
tests.vuizvui namespace.
You can use it like this:
{ config, tests, lib, ... }:
{
... other options of the foo service module ...
config = lib.mkIf config.foo.enable {
vuizvui.requiresTests = [ tests.vuizvui.foo ];
};
}
If a machine config enables the module foo (foo.enable = true) then the
"foo" test is also a constituent of the machine channel for the machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
The idea is that modules can define a list of test jobs which need to
succeed whenever the module is used.
In the end this should make channel updates a bit less frightening for
people not already confident in using NixOS.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Having <nixpkgs-config> in PATH doesn't help in anything if we actually
forget to add the right environment variable where we import the
<nixpkgs-config> from NIX_PATH.
The reason why I choose to use <nixpkgs-config> instead of directly
specifying the config in NIXPKGS_CONFIG is that we now have _one_
environment variable (NIX_PATH) to override everything from the
<nixpkgs> version to its config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This should make creating ~/.nixpkgs/config.nix obsolete and we can
solely decide whether we actually want these overrides by modifying
NIX_PATH alone.
The option isn't enabled by default, because this doesn't work if for
example /etc/nixos/configuration.nix is not readable by the user using
nix-env or importing <nixpkgs> by other means.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was glad that the issues because of the longstanding GHC determinism
bug (https://ghc.haskell.org/trac/ghc/ticket/4012) happened less
frequently with GHC 7.10.
Unfortunately, they still happen, as reported by @Profpatsch at
headcounter/deployment#19 so we're going to override the GHC derivation
with an additional attribute that is exported into the environment of
the builder.
This attribute causes GHC and all dependant packages to be rebuilt on
the Headcounter Hydra. The original issue was because we're using the
official NixOS binary cache as well as building everything from source.
It's helpful for not needing to rebuild the entire world, but for
Haskell packages it's harmful until the mentioned GHC bug has been
fixed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using environment.sessionVariables before, but
NixOS/nixpkgs@3f1354a added an option exclusively for this. It
internally still sets environment.sessionVariables, so it doesn't change
anything for us because we're overriding the full list anyway.
But should we switch from overriding to appending/prepending someday, we
could get unexpected behaviour, so that's why I'm switching to
nix.nixPath here.
Thanks to @devhell for bringing this to my attention.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
Since NixOS/nixpkgs@e3a5bca, signed binary caches are mandatory, so
let's set it in our default profile for vuizvui.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ugh... I must have been quite distracted while writing this.
Of course, doing a mkOverride on environment.sessionVariables instead of
environment.sessionVariables.NIX_PATH is going to clear *all*
sessionVariables instead of just replacing NIX_PATH.
This time however, I did a short test with:
nix-instantiate --eval --strict -E '
(import <nixpkgs/nixos/lib/eval-config.nix> {
modules = [ ./modules/profiles/common.nix ];
}).config.environment.sessionVariables
'
... to make sure I just didn't break it *again*.
Also, I'm going to immediately test this after the next evaluation, as
my current system is lacking quite a lot of necessary sessionVariables.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
That way we no longer need to rewrite anything from <nixpkgs> anymore,
because we only need to build one generation of the system and have the
right system-wide NIX_PATH for vuizvui.
For now however, let's test this properly before we can drop the rewrite
of nixos-rebuild and friends.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packageOverrides, we only want to return the vuizvui attribute set
and nothing more. But if we want to import <vuizvui/pkgs>, we want to
have access to <nixpkgs> as well, which is especially useful when using
the <vuizvui> channel.
However, in callPackageWith we're explicitely using the vuizvui
attribute which should override the whole set of <nixpkgs>, so that
references to vuizvui packages don't need to be explicitly namespaced
within vuizvui itself and we can easily override existing packages with
this method as well (like just define a vuizvui package and it overrides
the dependency for all of vuizvui's packages).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
Just moving the overrides into the base profile isn't enough here,
as we wouldn't be able to refer to packages anymore, because the global
nixpkgs.config override is now gone.
Instead, we're now putting pkgs.vuizvui.* into the NixOS module system
by a new profiles/common.nix, which is used unconditionally for all
machines.
Of course, the result of this is that we now need to change all
references to vuizvui-related packages, which also is a good thing,
because we will no longer shadow existing packages from upstream
nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
