Hi,
I've noticed that recent versions of Hydra no longer produce multiple outputs
per job. So in order to perform builds for multiple system targets, e.g.
i686-linux and x86_64-linux simultaneously, it now seems to be common that we
do something like this in a release expression:
{nixpkgs ? <nixpkgs>}:
let
pkgs = import nixpkgs {};
systems = [ "i686-linux" "x86_64-linux" ];
in
{
tarball = ...;
build = pkgs.lib.genAttrs systems (system:
pkgs.stdenv.mkDerivation { ... }
);
}
Apparently, it's also common to have a hardcoded list of system identifiers
from which an attribute set is composed (through lib.genAttrs {}) with unique
jobs per system architecture.
What I don't like very much about this approach is that fact that these system
identifiers are hardcoded. I would like to have the ability to configure target
architectures through Hydra's web interface, like we did when multiple outputs
per job were still supported. The Hydra web interface, however, does not have
the ability to configure lists of strings that can be passed as parameters to
these release expressions.
However, it still has the ability to configure multiple string values per
parameter (i.e. if I would specify 2 values for system then my expression gets
called twice). Using this I can still compose jobs that take system identifiers
from Hydra's web interface and having unique job names at the same time, but
I'm not sure if this is the recommended way to go:
{ nixpkgs ? <nixpkgs>
, system ? builtins.currentSystem
}:
let
pkgs = import nixpkgs { inherit system; };
in
{
tarball = builtins.listToAttrs [ ... ];
build = builtins.listToAttrs [
{ name = system;
value = pkgs.stdenv.mkDerivation { ... };
}
];
}
However, I find this approach a bit ugly and I have the feeling that Hydra's
ability to provide mutiple string values per jobset parameter is also going to
be removed at some point in the future.
So should I stick to this latter approach or would it be a good idea that we
can also pass list of strings to a release expression from Hydra's web
interface? Or is there even a better way to do it?
-- Sander
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
