| Commit message (Collapse) | Author | Age |
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Create a new events table for the new guix revision jobs, and update this when
processing a job starts, as well as finished with success or failure.
Additionally, remove the dependnency on open-inferior/container, as this
functionality isn't merged in to Guix master yet.
|
|
|
|
|
|
|
| |
Previously, the records for jobs would be deleted. It's useful to know when
jobs were inserted in to the database, as well as when they succeeded (if they
have). This change also makes it possible to keep track of jobs that have
failed, as they won't be deleted.
|
|
|
|
|
|
|
|
|
|
| |
And display this on the package page.
This uses a couple of new tables, and an additional field in the
package_metadata table.
Currently, the order of the licenses in the package definition isn't stored,
as I'm not sure the order in the list is significant.
|
|
|
|
|
|
|
| |
Store the location a package can be found at, and display this on the package
page.
If available, link off to the git repository containing the package.
|
|
|
|
|
|
|
|
| |
I'm thinking about adding more fields to this table, and the sha1_hash values
will make this tricker.
Therefore, remove the value, and adjust the existing code to cope. This commit
also adds a new test which coveres some of the changed functionality.
|
|
|
|
|
|
| |
Add some new pages /branches and /branch/... as well as a new git_branches
table. Also extend the email processing to enter the branch information in to
the database.
|
|
|
|
|
|
| |
Rather than just storing the URL in the guix_revisions and
load_new_guix_revision_jobs tables. This will help when storing more
information like tags and branches in the future.
|
|
These are based on the state of the current manually managed database.
|