recording the builds that are part of a jobset evaluation. We need
this to be able to answer queries such as "return the latest NixOS
ISO for which the installation test succeeded". This wasn't previously
possible because the database didn't record which builds of (say)
the `isoMinimal' job and the `tests.installer.simple' job came from
the same evaluation of the nixos:trunk jobset.
Keeping a record of evaluations is also useful for logging purposes.
against the set of current builds for the job). This ensures that
the builds with the highest ID are what we want in the channel, even
in case of reverts.
the derivations that the jobset currently contains. This is
necessary to allow the "latest" channel to contain the correct
builds when the sources of a jobset are reverted.
mainly to prevent all those Nixpkgs builds named "kde*" from
building at the same time. Since they all have the same slow
dependencies (qt, kdelibs) this tends to block the buildfarm.
the input build to be specified, as well as constraints on the
inputs of the inputs build. For instance, you can require that a
build has input `system = "i686-linux"'.
This is important when one binary build serves as an input to
another binary build. Obviously, we shouldn't pass a build on
i686-linux as an input to another on i686-darwin. Hence the
necessity for constraint.
The constraint are currently quite limited. What you really want to
say is that the "system" input of the other build has to match the
"system" input of this build. But those require a bit more work
since they introduce dependencies between inputs.
distinguish between jobs with the same name in different jobsets
(e.g. "trunk" vs "stdenv-branch" for Nixpkgs).
* Renamed the "attrName" field of Builds to "job".
* Renamed the "id" field of BuildSteps to "build".
