[bug-gsrc] Integration testing with Nix/Hydra

[Ludovic Courtès]

Hello,

Brian Gough <address@hidden> writes:

> I made a nix expression from your script to run against nixpkgs-libre.
> It seems to work ok on fencepost (using stdenvNative) but I'm not sure
> if it is the "correct" way to do it--I'm still learning the nix
> language.  I will refine it and look at what dependencies we are
> bringing in.
>
> I think we can easily restrict the build to our candidate package set
> by fixing the gnu entry in mirrors.nix to point a local directory, so
> we only bring in the specific GNU package versions we want.

Changing ‘gnu’ in mirrors.nix would allow us to fetch packages locally,
for instance; it wouldn’t allow us to select package versions, though,
since that’s what individual Nix expressions like
pkgs/tools/misc/coreutils/default.nix do.

> Incidentally, is there any documentation about how to write a Hydra
> jobset?  I looked at your guile-2-test.nix but couldn't figure it out
> from that.

I don’t think there is.  In principle it’s quite simple but that one,
which derives from pkgs/top-level/release.nix, is quite hairy.  :-)

I suggest looking at the job sets in the ‘gnu’ project
<http://hydra.nixos.org/project/gnu>, which are available at
<https://svn.nixos.org/repos/nix/hydra-config/gnu/trunk>.

So, a Hydra job set is an attribute set in the Nix language.  Each
attribute is evaluated by Hydra and corresponds to a Hydra job.  Most of
the type, a job takes parameters, which are passed by Hydra, at least
the system type (e.g., ‘i686-linux’); in the case of hydra-config/gnu,
jobs also typically take a fresh checkout as a parameter.

To test SRC, we could typically mimic pkgs/top-level/release.nix like
this:

--8<---------------cut here---------------start------------->8---
with (import ./release-lib.nix);

mapTestOn {
  acct = linux;
  aspell = linux;
  auctex = linux;
  autoconf = linux;

  [...]

  zile = all;
}
--8<---------------cut here---------------end--------------->8---

And that should be enough.  Most build results will be cached anyway, so
that won’t cost much.

Hmm I realize we can easily add such a job set to hydra-config/gnu,
esp. since I can administrate it on Hydra’s web interface.  I’ll look
into it and report back.

Thanks,
Ludo’.