| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
As the page can be quite long, so jumping to the top and bottom is really
useful.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Which does the same thing as parse-result-limit, which may have an overly
specific name.
|
| |
|
|
| |
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.
|
| |
|
|
| |
Which shows the output for that job.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
As that seems neater.
|
| |
|
|
|
| |
It isn't very useful, as you have to know the commits. Now that there's Git
branch information, it should be possible to access this in a more useful way.
|
| |
|
|
|
|
| |
To the compare/derivations page. Previously, the compare/derivations page was
comparing more than the derivations, notably the package metadata. This change
avoids that, and also reduces the information overload on the compare page.
|
| |
|
|
| |
Only those where it's appropriate for the data, like commit hashes.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Also flip the branch and revision columns around, and add date information to
the branch column.
|
| |
|
|
|
| |
And always link to the revision page. Now the label let's you know if you
should expect information or not for that revision.
|
| |
|
|
|
| |
Make it similar to the revision page, as some of the information, like the
link to the relevant CGit instance might be available.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
So that they can also be used for the /branch/foo/latest-processed-revision
pages. The content is the same, but the title, link, and some of the links on
the page are different.
|
| |
|
|
| |
It's useful to know the commit.
|
| |
|
|
|
|
| |
This makes is easier to get the latest data for a branch in a single request,
rather than making one request to find the latest revision, then another to
get the data.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
| |
I'm not sure quite how to treat these yet, but for now, just stick with the
previous behaviour of showing revisions which haven't been processed yet,
along with the ones that have been successfully processed.
|
| |
|
|
| |
Otherwise, concurrent requests can cause the output to be interleaved.
|
| | |
|
| |
|
|
|
| |
This'll help the a service manager (like the shepherd) know when the service
is ready, which at the moment, means the database migrations have happened.
|
| |
|
|
| |
As this means it can find the relevant files.
|
| |
|
|
| |
So that it can always find psql.
|
| | |
|
| | |
|
| |
|
|
|
| |
Install the assets and sqitch files, as they are needed. Remove the test
related sources.
|
| |
|
|
|
|
| |
This runs Sqitch on startup, which should make managing the database easier,
as you just have to restart the service with this option, and the database
should be updated if necessary.
|
| |
|
|
|
|
| |
This indicates currently if the database is accessible and a simple query can
be performed. I'm mostly looking at using this when writing a system test for
this service.
|
| |
|
|
|
|
|
|
|
| |
Previously, one of the first things that happened when responding to a request
was a database connection was made, even when serving the CSS. This is
unnecessary, so move the database connection handling in to the controller.
Also, to allow for separating it out from the assets, separate the assets out
from the parts of the controller that require a database connection.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|