| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
| |
Older versions of the glibc-locales package just contain the UTF-8 variants,
not utf8.
|
| | |
|
| |
|
|
|
| |
This is a recent addition, so to support loading revisions without it, better
handle the error when loading the module.
|
| |
|
|
| |
Otherwise modules from outside of the inferior can leak in.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
As this is useful to know.
|
| |
|
|
|
|
|
|
|
|
|
| |
When loading data from an inferior Guix, first build it's latest version of
glibc-locales, and include that in the environment from the inferior.
This improves locale support, which is currently relevant for extracting lint
warnings.
Without this change, you'd only be able to switch to locales supported by the
glibc-utf8-locales package, assuming that the right version is available.
|
| |
|
|
| |
In the load-new-guix-revision module.
|
| |
|
|
| |
In the load-new-guix-revision module.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
To increase the log output speed, avoiding inserting one character at a time
in to the database.
|
| |
|
|
|
| |
These changes allow processing emails again, and just creating job and branch
entries where data is missing.
|
| | |
|
| | |
|
| |
|
|
| |
This allows running jobs manually that have failed.
|
| | |
|
| |
|
|
|
|
| |
Reserve some capacity to process revisions which are the tip of a branch. This
should reduce the time between new revisions appearing, and then being
processed.
|
| |
|
|
| |
So that they aren't retried again and again.
|
| |
|
|
|
|
| |
This should speed up processing new revisions, reduce latency between finding
out about new revisions and processing them, as well as help manage memory
usage, by processing each job in a process that then exits.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is working towards running the jobs in parallel. Each job looks at the
records in the database, and adds missing ones. If other jobs, running in
different transactions insert the same missing records at the same time, this
could cause an error.
Therefore, to just avoid this problem, lock before inserting the data. This
will allow the jobs to be processed in parallel, and it shouldn't have too
much of an effect on performance, as the slow bit is outside of the
transaction.
|
| |
|
|
|
|
|
| |
This is in preparation for running jobs in parallel. The channels code in Guix
uses a cached copy of the Git repository. Multiple jobs can't concurrently
access this without causing issues, so use an advisory lock to ensure that
only one job is using the repository at a time.
|
| |
|
|
| |
This helps when working out which connection to the database is doing what.
|
| |
|
|
| |
It doesn't work as intended unless the module is also specified, so do that.
|
| |
|
|
|
| |
If the job started, and then was restarted, the row will already exist. So
don't error on a conflict.
|
| |
|
|
|
|
| |
To better separate the code that needs to happen after a lock has been
acquired to allow concurrently loading revisions without concurrent insertion
issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Replace the Guile-side HTML escaping with a less complete, but hopefully
faster PostgreSQL side HTML escaping approach.
Also, allow reading part of the log, by default, the last 1,000,000
characters, as this should render quickly.
|
| |
|
|
| |
So that this is logged.
|
| |
|
|
|
| |
This part of the soft-port seems to be called, but I don't know why, and
trying to close the output port causes issues.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Try to isolate the code that inserts in to the database, so that the relevant
tables can be locked during this time.
|
| |
|
|
| |
That don't rely on timing a single function.
|
| | |
|
| |
|
|
| |
If a substitute fails, just build it anyway.
|
| |
|
|
|
|
|
| |
Conventionally, you'd process the oldest job in a queue, but at the moment, it
would be more useful to have recent information more promptly, and fill in the
historical gaps later. I'm not sure this'll always be the case, but for now,
flip the order in which jobs are processed.
|
| |
|
|
|
| |
As these are used for logging, which is done on a line by line basis. Remove
the now redundant calls to (force-output).
|
| |
|
|
| |
As this is useful information.
|
| | |
|
| |
|
|
| |
It's useful to know the commit.
|
| |
|
|
| |
To help with debugging.
|
| |
|
|
|
|
| |
And use it for the hosting the inferiors, rather than computing the guix
package at runtime. This simplifies the behaviour when the Guix Data Service
is deployed as a Guix package.
|
| |
|
|
|
| |
Within an inferior. Just use the presence of open-inferior/container directly,
as this is more explicit.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
If the repl enters a bad state, attempt to exit, and catch failures in the
parent process, and rollback the open transaction.
|