| Commit message (Collapse) | Author | Age |
|
|
|
| |
As the Guix Build Coordinator can build one derivation many times.
|
|
|
|
| |
This effectively makes adding build status entries idempotent to some degree.
|
|
|
|
|
|
|
| |
Like Cuirass, or the Guix Data Service. This isn't so necessary with Cuirass,
as the derivation/output are unique identifiers, but for the Guix Build
Coordinator, one derivation/output can be built many times, with potentially
differing results.
|
|
|
|
|
|
| |
The Guix Build Coordinator doesn't record timestamps for events
currently. This is something to fix, but allow for build statuses without
timestamps as they're not necessary.
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
| |
|
|
|
|
|
| |
This is to allow for build servers where only the substitutes should be
queried, and it shouldn't be assumed that they're running Cuirass.
|
|
|
|
|
| |
This follows on from 79993bfaeff3097d37838bc0636fc20c6fc4283d, disassociating
the relevant derivations from the revisions.
|
| |
|
|
|
|
|
| |
Given that a commit, regardless of what repository it comes from should
contain the same exactly the same data, just track jobs by commit.
|
|
|
|
| |
This greatly improves the performance of the derivation-outputs page.
|
|
|
|
| |
It's been replaced by the package_derivations_by_guix_revision_range table.
|
|
|
|
|
|
|
| |
Rather than just the native system. I'm not quite sure of the value here, as I
guess system tests should behave the same regardless of the way the software
is compiled, but this seems like it could be useful, and being explicit about
the system the derivation is for is good.
|
|
|
|
| |
To allow for deferring it in a transaction when deleting derivations.
|
|
|
|
|
| |
Change target to '' if it matches system, as this matches the updated way of
storing derivations.
|
|
|
|
| |
These are the ones that relate to Guix pull.
|
|
|
|
|
| |
So that you can have the Guix Data Service only pay attention to some of the
branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using the system values as targets, and remove package derivation entries
where this is the case.
Switch the non-cross derivation case to have a target of "", rather than
matching the system, as this makes more sense, and is more consistent now that
the target values no longer match the system values.
Hardcode some more correct target values, and use these instead. Hopefully
this can be better integrated with Guix in the future.
This commit also includes a migration attempting to shrink some indexes.
|
| |
|
|
|
|
|
| |
Rather than expecting it always to be "guix", store the expected value in the
database, and use the value of the header to find the relevant repository.
|
| |
|
|
|
|
| |
For derivation_source_files.
|
|
|
|
| |
This will allow serving the nars for derivation source files.
|
|
|
|
|
|
| |
This is to aid rendering of narinfo files. They're requested with the path
/HASH.narinfo, so to quickly find the relevant derivation, this index can be
used.
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This commit adds the tables, as well as code to support extracting data from
narinfo files.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
There's already the package_versions_by_guix_revision_range table, but I think
it would be also useful to be able to see how derivations change over time.
|
| |
|
|
|
|
|
|
|
|
| |
Add a new event 'retry', and run jobs where the number of retry events is
greater or equal to the number of failure events.
Also add an index to the git_branches table to make the finding jobs query a
bit faster.
|
|
|
|
|
|
|
|
|
|
|
| |
The git_branches table had 'NULL' values for some commits where the branch was
deleted, importantly this was the string 'NULL', not an actual NULL value.
This commit fixes that, migrating the existing values to be '', and changing
the relevant code.
The primary key is also extended to include the datetime field, as this is
important to allow a branch to be deleted twice.
|
|
|
|
| |
To speed up the rendering of the index page.
|
|
|
|
|
|
|
| |
This isn't new information, but derived from information already in the
database. It's collected here to make querying faster.
The table is updated when each new revision is entered.
|
|
|
|
|
|
|
|
|
| |
To associate a set of lint checkers with a specific revision. While there is
the association through the lint warnings, that only works for checkers where
there are lint warnings for that revision.
Therefore, to allow finding all the checkers for a specific revision, also
associate them directly with the revision.
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the relevant tables and code to store lint warnings in the
database.
Currently, only lint checkers which don't require access to the network will
be run, as this allows the processing to happen without network access. Also,
this functionality won't work in older versions of Guix which don't expose the
lint warnings in a compatible way.
|
|
|
|
|
| |
These changes allow processing emails again, and just creating job and branch
entries where data is missing.
|
|
|
|
| |
To allow for having branches in multiple git repositories.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The licenses table, along with the package_metadata table had duplicate
values. This could happen as the unique constraints on those tables didn't
properly account for the nullable fields.
The duplicates in those tables also affected the license_sets, packages,
package_derivations tables in a similar way. Finally, the
guix_revision_package_derivations table was also affected.
This commit adds a migration to fix the data, as well as the constraints. THe
code to populate the licenses and package_metadata tables is also updated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the query for the jobs page was really slow, as it checked the
load_new_guix_revision_job_log_parts table for each job, doing a sequential
scan through the potentially large table.
Adding an index didn't seem to help, as the query planner would belive the
query could return loads of rows, where actually, all that needed checking is
whether a single row existed with a given job_id.
To avoid adding the index to the load_new_guix_revision_job_log_parts table,
and fighting with the query planner, this commit changes the
load_new_guix_revision_job_logs table to include a blank entry for jobs which
are currently being processed. This is inserted at the start of the job, and
then updated at the end to combine and replace all the parts.
This all means that the jobs page should render quickly now.
|
|
|
|
|
|
|
| |
So that it can easily be shown through the web interface. There's two tables
being used. One which temporarily stores the output as it's output while the
job is running, and other which stores the whole log once the job has
finished.
|