The check to see whether a build had been scheduled in a previous
evaluation took about 200 ms for the nixpkgs:trunk jobset. Given
that it has more than 15000 builds, this added up to a lot. Now
it takes 0.2 ms per build.
This happened in a pathological case in Nixpkgs: the "grub" job is
evaluated for i686-linux and x86_64-linux, but in the latter case it
returns the same derivation as in the former case. So only one build
should be added.
This gets rid of the openHydraDB function and ensures that we
open the database in a consistent way.
Also drop the PostgreSQL sequence hacks. They don't seem to be
necessary anymore.
When checking whether the jobset is unchanged, we need to compare with
the previous JobsetEval regardless of whether it had new builds.
Otherwise we'll keep adding new JobsetEval rows.
In particular the /pkg action is now O(lg n) instead of O(n) in the
number of packages in the channel, and listing the channel contents
no longer requires calling isValidPath() on all packages.
Derivations (and thus build time dependencies) are no longer included
in the channel, because they're not GC roots. Thus they could
disappear unexpectedly.
* Don't use isCurrent anymore; instead look up builds in the previous
jobset evaluation. (The isCurrent field is still maintained because
it's still used in some other places.)
* To determine whether to perform an evaluation, compare the hash of
the current inputs with the inputs of the previous jobset
evaluation, rather than checking if there was ever an evaluation
with those inputs. This way, if the inputs of an evaluation change
back to a previous state, we get a new jobset evaluation in the
database (and thus the latest jobset evaluation correctly represents
the latest state of the jobset).
* Improve performance by removing some unnecessary operations and
adding an index.
Prepared statements are sometimes much slower than unprepared
statements, because the planner doesn't have access to the query
parameters. This is the case for the active build steps query (in
/status), where a prepared statement is three orders of magnitude
slower. So disable the use of prepared statements in this case.
(Since the query parameters are constant here, it would be nicer if we
could tell DBIx::Class to prepare a statement with those parameters
fixed. But I don't know an easy way to do so.)
For schema upgrades, hydra-init executes the files
src/sql/upgrade-<N>.sql, each of which upgrades the schema from
version N-1 to N. The upgrades are wrapped in a transaction.
The abbreviated Git revision hash (e.g. "267480b") is typically
contained in ‘gitTag’ as well, but the latter can contain other
elements as well, e.g., the delta to the closest tag. That may
be undesirable in version strings, so this is an alternative.
The ‘revCount’ attribute is the number of commits in the history
of the revision. This is useful if you need a monotonically
increasing version number.
The ‘gitTag’ attribute is the output of ‘git describe’, e.g.
‘v1.0.4-14-g2414721’ to indicate that the current revision is 14
commits after the tag ‘v1.0.4’.
In hydra-evaluator, reuse an SVN working copy between runs (similar to
what we do with Git and other input types). This reduces network
traffic in the common case.
Also, don't use nix-prefetch-svn. It doesn't do anything useful.
to predict how much disk space a package will require.
* Compute the output / closure size using the info stored in the
Nix database (rather than doing a slow "du").
even when all the remote build slots are in use. The evaluator can
cause builds if Nix expressions import derivations (e.g. in
pkgs/build-support/vm to compute the RPM/Deb closures). If there
are no free build slots, the evaluator can hang for a long time.
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.
faster, from about 4.5s to 1.0s for the global "latest" channel.
Note that the query is only fast if the "IndexBuildsOnJob" and
"IndexBuildsOnJobAndIsCurrent" indices are dropped - if they exist,
PostgreSQL will use those instead of the more efficient
"IndexBuildsOnJobFinishedId" index. Looks like a bug in the planner
to me...
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".
