[Nix-dev] [Hydra] Configuration of system identifiers

[Sander van der Burg - EWI]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130927/6b4adc5d/attachment.html