| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
This is mostly a workaround for the occasional problems with the guix-commits
mailing list, as it can break and then the data service doesn't learn about
new revisions until the problem is fixed.
I think it's still a generally good feature though, and allows deploying the
data service without it consuming emails to learn about new revisions, and is
a step towards integrating some kind of way of notifying the data service to
poll.
|
| |
|
|
|
|
|
|
|
| |
This will hopefully provide a less expensive way of finding out if a scheduled
build is probably blocked by other builds failing or being canceled.
By working this out when the build events are recieved, it should be more
feasible to include information about whether builds are likely blocked or not
in various places (e.g. revision comparisons).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
And create a proper git_branches table in the process.
I'm hoping this will help with slow deletions from the
package_derivations_by_guix_revision_range table in the case where there are
lots of branches, since it'll separate the data for one branch from another.
These migrations will remove the existing data, so
rebuild-package-derivations-table will currently need manually running to
regenerate it.
|
| | |
|
| |
|
|
|
|
| |
This might be useful for working out when a non-master branch contains a newer
version of a package, or someone has sent in a patch for a newer version
already.
|
| |
|
|
|
| |
The database size is growing, but it's hard to know what parts are growing the
fastest. These metrics will hopefully help with understanding that.
|
| |
|
|
|
|
| |
These are related things, but somewhat separate. This change should make it
easier to deal with changes regarding querying build servers, and querying
substitute servers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Copied over from the Mumi code.
|
| |
|
|
|
|
|
|
| |
This, along with the way of specifying which branches are processed is a way
to manage the data stored within the Guix Data Service.
This only goes so far, it doesn't delete derivations, but it does delete some
of the information related to a revision.
|
| |
|
|
| |
These are the ones that relate to Guix pull.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In the same manor that Guix publish does. This is working towards being able
to serve substitutes for derivations.
|
| |
|
|
| |
... entries in to a separate module, to split the code up a little further.
|
| | |
|
| |
|
|
| |
To store code used for rendering HTML across multiple controllers.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This computes and displays the tokens needed to send build events to the Guix
Data Service.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As this leaves a process running, it's better just to stop the database
manually.
|
| |
|
|
| |
So that they're actually set for sqitch.
|
| |
|
|
|
| |
To better manage the environment, and stop the database upon completion of the
tests.
|
| |
|
|
|
|
|
| |
This is aimed at testing using pg_tmp, to create a temporary test
database (and instance of PostgreSQL). This is both useful for testing all the
migrations, but should also be useful for running the tests within the guix
package.
|
| | |
|
| |
|
|
|
| |
This can be used with the mbox files for the guix-commits mailing list to add
older emails in to the database.
|
| |
|
|
|
| |
This is to be able to serve a readable version of the README on the site,
allowing those without Emacs to more easily read it.
|
| |
|
|
| |
I think the .go files should be in lib, rather than share.
|
| |
|
|
|
|
|
| |
Add tests around the package module, extract out the use of the
inferior-package record assessors so that they aren't part of the tests, and
switch across the package-metadata module to use
insert-missing-data-and-return-all-ids.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This allows easily processing an individual job by id. This may be useful to
use manually, but also when processing jobs in parallel, as forking doesn't
work well with the libpq library used by squee.
|
| |
|
|
|
| |
Install the assets and sqitch files, as they are needed. Remove the test
related sources.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This to help test code which uses the (guix inferior) module.
|
| |
|
|
|
| |
Using the test driver from build-aux/test-driver.scm, as this shows the test
errors when tests fail.
|
| |
|
|
|
|
|
|
|
| |
The query parameters feed in to the results shown, but also forms on
pages. Validation is important to avoid errors and security issues, but it's
also important to provide appropriate feedback to the user.
This module provides some utilities and structure around handling query
parameters.
|