| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
As this is the way they're sorted in the derivation.
|
| |
|
|
|
|
| |
Between b13b9384bc43bf93c754c037956c8ef9a99c2b41 and
601171a9bc7ca6e4acb932895a07c0ca9aedfdac, this method failed, so catch the
error to allow loading the affected revisions.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Move the bit about the paramstring to after the database setup, as you need to
have set the password.
|
| | |
|
| |
|
|
|
|
|
|
| |
Ideally this would go in to the database somehow as well, but the only idea I
have for that is pass in a pipe, and then spawn a thread to read from the
other end of that pipe in a loop to send the output to the database.
That hasn't been written yet, so just send the output to stderr for now.
|
| | |
|
| |
|
|
|
| |
The lack of these meant that versions on other branches could appear in the
results.
|
| | |
|
| |
|
|
|
|
| |
Given that the .envrc file and direnv setup in the previous step may provide
the PostgreSQL tools that you need to run here, it's probably more sensible to
re-order the steps in this way.
|
| |
|
|
|
| |
In to their own modules. This should help make the code more understandable,
and allow future refactoring for readability.
|
| | |
|
| |
|
|
|
| |
Move it out of the main controller and html modules to better separate the
code, which should allow to make it easier to read in the future.
|
| |
|
|
|
|
| |
Move the code to a more specific controller and html module. There's a lot of
code related to the revision pages, and having it separated will help with
refactoring it.
|
| |
|
|
| |
As I believe it's unused.
|
| |
|
|
|
|
| |
Move the code out of the main controller and html modules. There's now too
much code in these modules, so begin to separate the functionality, starting
with the small amount of code for the jobs pages.
|
| |
|
|
|
|
|
|
|
|
| |
This is to compare the state of a branch (or two different branches) at two
different times. This complements the ability to compare by revision to be
able to just compare by date and time. The relevant revisions are determined,
and then compared as normal.
This is only a very rough initial implementation, as I'm hoping to refactor
the code to reduce duplication.
|
| | |
|
| |
|
|
| |
To get the guix revision that was on a branch at a given date and time.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Uses of this have been replaced with parse-query-parameters.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
As this is useful when working with pg_tmp.
|
| |
|
|
| |
To fix the order when the first_datetime matches.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, the assets would be served from the store normally, but this meant
that they were read from disk each time, and stat calls were used to determine
when they were last modified.
This doesn't work for files in the store, as the timestamps are normalised,
therefore add a renderer that takes advantage of the asset directory being in
the store. All the files are read at startup, and then stored in memory. Also,
the process start time is used as a value for the last modified header, which
isn't ideal, but it's better than 1970.
|
| |
|
|
|
| |
To allow looking up if the assets are in the store, which will happen if the
Guix Data Service is running from a Guix package.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
As this name is more specific.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
As there is an initial version of this feature now.
|
| |
|
|
| |
As I think this makes more sense than "including graphs".
|
| |
|
|
| |
As this means that like psql, the unix socket will be used.
|
| | |
|
| |
|
|
|
| |
To keep the page length down. All branches can still be seen on the page for
specific repositories.
|
| |
|
|
| |
The git_branches.commits column doesn't allow NULL values.
|