| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It now converts the recursive value to a boolean.
|
|
|
|
|
|
| |
The HTML is very rough, and the way it's displayed is also rough, but it does
provide a way to understand the derivation. I'm also unsure it's a perfect
representation, but it's a start at least.
|
| |
|
|
|
|
|
|
| |
Return integer values for ids, rather than strings (as this type is more
appropriate). Also, better parse the derivation arguments and environment
variables.
|
| |
|
|
|
|
|
| |
Some filtering options need adding for the system and target, as it's
currently hardcoded, but the general page does work.
|
|
|
|
|
| |
There's already the package_versions_by_guix_revision_range table, but I think
it would be also useful to be able to see how derivations change over time.
|
|
|
|
| |
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.
|
| |
|