releases as a dynamic view on the database was misguided, since
doing thing like adding a new job to a release set will invalidate
all old releases. So we rename release sets to views, and we'll
reintroduce releases as separate, static entities in the database.
doesn't scale), and include links for jobset/job specific pages.
The main page now lists the projects.
* Overview pages for jobsets and jobs.
* Links to the channels.
* Jobsets are now defined and edited in a separate action.
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".
