| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
Previously, the behaviour was to accept multiple values, but enable just
allowing one value to be entered.
|
|
|
|
|
| |
To add or update the relevant query parameter, rather than replacing all the
query parameters with the new value.
|
| |
|
|
|
|
| |
Account for equivalent derivations, rather than counting them as unknown.
|
|
|
|
|
|
|
|
| |
The equivalent_derivations table was an experiment that didn't work, so switch
to using the derivations_by_output_details_set table.
Also take the build server id as input, as this allows selecting derivations
which have no known build for the relevant build server.
|
|
|
|
| |
So you can select to query specific build servers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Rather than just counting builds where the derivation matches, select builds
based on the derivation outputs, which accounts for different but equivalent
derivations.
|
|
|
|
|
| |
As this will hopefully provide a faster way of associating derivations with
builds.
|
|
|
|
|
|
|
|
|
|
|
| |
Derivations are effectively equivalent if they produce the same set of
outputs, which is possible because of the equivalence of fixed output
derivations. A fixed output derivation can be different, but equivalent,
because it produces the same fixed output.
To better allow tracking equivalent derivations, primarily to allow working
out what derivations might correspond to a build, store the sets of derivation
outputs, and which derivations they relate to.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The join on derivation_outputs was completely wrong, so fix that.
Also, rather than only selecting outputs where there's a corresponding build,
just eliminate outputs where there is an entry in the nars table, fetched from
the relevant build server.
Also just look at x86_64-linux derivations, because there's no filtering on
relevant derivations for a build server at the moment.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than eliminating any derivation that has a known build, eliminate those
derivations, but also equivalent derivations as well.
For selecting the derivations in a revision, join on the equivalent
derivations, as all the equilalent derivations need checking as well, as it's
unknown which one Cuirass would have associated the build against.
Also, filter for x86_64-linux, to avoid checking for crossbuilt things. This
should be replaced by some way of describing what derivations a build server
has.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Duplicate builds could creep in if the code to create them ran concurrently. I
didn't exclude them initially, as I was unsure if there should be such a
restriction, but at least for now, Cuirass builds map exactly to a single
derivation, so use the same restriction here.
|
|
|
|
| |
As some nars can be bigger than the size of an int.
|
|
|
|
| |
As some nars can be bigger than the maximum size of an int.
|
|
|
|
| |
Otherwise it's hard to associated narinfo files to build servers.
|
|
|
|
| |
As this helps when finding builds relating to specific derivations.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
To store code used for rendering HTML across multiple controllers.
|
|
|
|
| |
As as new derivations are loaded, the contents of the page can change.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As well as making it possible to only query build servers for builds relating
to a specific revision.
|
| |
|
|
|
|
|
|
|
|
| |
Cuirass provides a timestamp field in build responses, and sometimes this
means when the build was scheduled, but when the build is finished, it's the
stoptime.
So only use the timestamp when the build hasn't finished.
|
| |
|
|
|
|
|
| |
This commit adds the tables, as well as code to support extracting data from
narinfo files.
|
| |
|
| |
|
| |
|
|
|
|
| |
To allow for expanding it, without cluttering the root controller.
|
| |
|
|
|
|
|
|
|
| |
Previously, all the entries for the branch were deleted, but not, only the
entries for the branch, that are present in the revision that was loaded will
be deleted. This is more efficient, as it avoids deleting and recreating
entries in the table that shouldn't have changed.
|
|
|
|
|
|
|
| |
Allow for build status information to be submitted by POST request. This
required some changes to the builds and build_status tables, as for example,
the Cuirass build id may not be available, and the derivation may not be know
yet, so just record the derivation file name.
|