| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
It now actually looks at the fields which have been provided.
|
| | |
|
| |
|
|
| |
As previously the pages would render, but with no data.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Where there are multiple interrelated fields, then it's useful to only apply
the default if another field hasn't been specified.
|
| | |
|
| |
|
|
| |
Particularly to support checkboxes.
|
| | |
|
| |
|
|
| |
Mostly to enable passing the cache-control header.
|
| |
|
|
|
|
| |
Given that the headers may be the same, regardless whether it's HTML or JSON
being sent in the body of the response, I think it makes more sense to handle
the headers in the controller.
|
| | |
|
| |
|
|
|
| |
To get git repository and git branch information suitable for the revision
page.
|
| |
|
|
| |
This is useful for some queries with duplicated parts of the results.
|
| |
|
|
| |
Date and Commit were the wrong way around.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is mostly for the JSON output, as it allows much more information to be
included.
|
| |
|
|
| |
To the query parameters module.
|
| | |
|