Commit Graph

55 Commits

Author SHA1 Message Date
ed132cf1fc Remove obsolete JobStatus source 2013-10-03 15:05:53 +02:00
edb88ef452 Remove unused ActiveJobs source 2013-08-20 15:22:46 +02:00
1776d9118f Rename aggregate members to constituents 2013-08-15 02:33:10 +02:00
81322de94e Show aggregate members 2013-08-15 00:30:19 +02:00
d58142b3f0 Store aggregate members in the database
For presentation purposes, we need to know what builds are part of an
aggregate build.  So at evaluation time, look at the "members"
attribute, find the corresponding builds in the eval, and create a
mapping in the AggregateMembers table.
2013-08-14 01:59:29 +02:00
002ac9ef63 Merge in the first bits of the API work
The catalyst-action-rest branch from shlevy/hydra was an exploration of
using Catalyst::Action::REST to create a JSON API for hydra. This commit
merges in the best bits from that experiment, with the goal that further
API endpoints can be added incrementally.

In addition to migrating more endpoints, there is potential for
improvement in what's already been done:
* The web interface can be updated to use the same non-GET endpoints as
  the JSON interface (using x-tunneled-method) instead of having a
  separate endpoint
* The web rendering should use the $c->stash->{resource} data structure
  where applicable rather than putting the same data in two places in
  the stash
* Which columns to render for each endpoint is a completely debatable
  question
* Hydra::Component::ToJSON should turn has_many relations that have
  strings as their primary keys into objects instead of arrays

Fixes NixOS/hydra#98

Signed-off-by: Shea Levy <shea@shealevy.com>
2013-07-02 14:00:46 -04:00
507e5bb190 Drop unused "disabled" columns 2013-05-03 16:39:17 +02:00
45a1bb9926 Remove unnecessary parentheses in SQL query
These make SQLite 3.7.16.2 crash.

http://hydra.nixos.org/build/4815315
2013-04-29 21:38:57 +02:00
edbe531ccc On build pages, provide a link to the build's first eval 2013-02-21 18:34:34 +01:00
10882a1ffd Add multiple output support
This requires turning the outPath columns in the Builds and BuildSteps
tables into separate tables, and so requires a schema upgrade.
2013-02-13 16:49:28 +00:00
30e5185acf Remove the logfile and logSize columns from the database
It's pointless to store these, since Nix knows where the logs are.
Also handle (in fact require) Nix's new log storage scheme.  Also some
cleanups in the build page.
2013-01-22 22:48:02 +01:00
67aefde62c Remove trailing whitespace 2013-01-22 14:41:02 +01:00
fd50ac1d4e Store the inputs of each evaluation in the database
Achtung: this requires a schema upgrade via "hydra-init".
2012-04-15 18:36:36 +00:00
179b012a8e Open the DB using Hydra::Model::DB->new
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.
2012-03-13 12:10:19 +01:00
68a867da67 Merge the BuildResultInfo table into the Builds table 2012-03-12 20:47:29 +01:00
25334715f8 Merge the BuildSchedulingInfo table into the Builds table
This simplifies the code and improves performance since it reduces
the number of joins.
2012-03-12 20:47:29 +01:00
9032c55aa6 Keep track of the database schema version
The singleton table SchemaVersion contains the current version
of the Hydra database schema.  This can be used to upgrade the
schema on the fly.

Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
b25761d7b2 hydra: added missing fields to query 2010-06-03 09:17:24 +00:00
bb7f82840b Hydra: Add support for maxSilent meta attribute (also already added timeout, but not implemented the actual timeout for the build yet) 2010-05-26 08:03:59 +00:00
7daca03e78 * Store jobset evaluations in the database explicitly. This includes
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.
2010-03-05 15:41:10 +00:00
31f68756c5 fix wrong dbix:class:loader generation 2010-02-25 10:22:03 +00:00
4dccd3c620 generated schema with new dbix class schema loader, grrrrrr 2010-02-25 09:50:04 +00:00
12edc4b8e2 * Speed up the jobstatus query a little bit. 2010-02-12 20:51:24 +00:00
d8cc0bbb5d * Make the "latest succeeded" query (used by the "latest" channel)
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...
2010-02-12 14:49:32 +00:00
68c60b4c66 * hydra: added index, actual build time (buildstep with same outpath, so without deps) of the build 2010-02-11 12:23:46 +00:00
61ad98f982 revert change to dbix::class generated code 2010-02-05 19:41:26 +00:00
9dba2127cb * hydra: 'new' UI for project/jobset/job/build 2010-02-05 14:48:22 +00:00
2fb05b34bf add support for git as jobinput 2009-11-17 15:16:41 +00:00
9aa70716ad 2009-10-26 17:03:48 +00:00
cb2493eca9 * Store the jobset's nixExprPath and nixExprInput fields in a build to
allow it to be cloned (re-executed with modified inputs) later and
  to provide some traceability.
2009-10-26 13:33:48 +00:00
a515c5fef2 2009-10-23 15:05:16 +00:00
929cbe7b7c * Adding persistant releases. A release is a named set of builds. 2009-10-21 15:44:17 +00:00
686b6271d2 * Cleaned up the foreign key constraints.
* Generate SQLite and PostgreSQL schemas from hydra.sql.
2009-10-21 12:25:43 +00:00
cec3201720 * Renaming "release sets" to "views" (not finished yet). Having
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.
2009-10-15 21:35:19 +00:00
6cedee5476 * Allow jobsets to be disabled. 2009-10-08 11:39:16 +00:00
16f2d003b2 * In the last succeeded / job status queries, use the Builds.isCurrent
column instead of Jobs.active.
2009-10-07 15:45:17 +00:00
48d8871dbc * Only show status changes from successful to failed and failed to
successful (not between different kinds of failure).
2009-10-07 13:59:12 +00:00
7ae263a23a * Make the queries more readable. 2009-10-07 13:40:58 +00:00
e9cf409d80 * Mark the "current" builds in a jobset, i.e. those corresponding to
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.
2009-10-02 16:06:28 +00:00
fa364fa333 * PostgreSQL compatibility. 2009-07-09 15:08:39 +00:00
1aec78014d * In the job status and error pages, show when the status of a job
last changed.
2009-07-09 14:48:15 +00:00
5bdd5e7152 * Added a maintainers field to the Builds table.
* Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
e457be469c sequence fix for postgresql 2009-05-11 13:56:52 +00:00
b52796feac check getHydraPath in stead of Envvar HYDRA_DBI directly 2009-05-09 16:10:50 +00:00
f2a1fb3937 Added sequences for auto increment primary key columns (for PostgreSQL) 2009-05-07 13:30:55 +00:00
d774cd6f18 changed queries for compatibility with postgresql 2009-04-28 14:21:33 +00:00
018585dba8 * In the job status page and the channels, pick the build with the
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).
2009-04-22 13:55:20 +00:00
16a84f4bf5 * Big speed-up of the job status page and the channel generation (such
as the manifest).  The builds are now determined in one SQL query
  rather than a zillion ones.
2009-04-03 15:37:21 +00:00
ae364b9e5f * Represent jobs explicitly in the DB. 2009-03-13 14:49:25 +00:00
f2f586d842 * Disambiguate jobs by jobset name. I.e. jobs with the same name in
different jobsets are not considered the same job.
2009-03-12 23:46:17 +00:00