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.
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.
Between b13b9384bc43bf93c754c037956c8ef9a99c2b41 and
601171a9bc7ca6e4acb932895a07c0ca9aedfdac, this method failed, so catch the
error to allow loading the affected revisions.
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.
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.
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.
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.
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.
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.
