highest ID rather than the highest timestamp. Otherwise, if a build
from revision N finishes after a build from revision N + 1, then
the build from revision N will end up in the channel. Thus, the
channel contents will be out of sync.
This is still not quite correct: if a revision *reverts* to an older
build, the channel will still end up out of sync, because Hydra
won't schedule the build again (after all, it has already done it).
A better fix would be to add a separate timestamp denoting when the
build was last "current" (i.e. corresponding to the "head revision"
of its job).
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".
Note: to upgrade old databases, do a dump with an old Sqlite first;
dumping with a new Sqlite will silently discard (!) the contents of
the ReleaseSetJobs table.
failed in a previous build. This is essential for Nixpkgs: we don't
want to keep doing the same failed dependency (say, Glibc) over and
over again for a few hundred jobs.
