Previously, all the entries for the branch were deleted, but not, only the
entries for the branch, that are present in the revision that was loaded will
be deleted. This is more efficient, as it avoids deleting and recreating
entries in the table that shouldn't have changed.
Allow for build status information to be submitted by POST request. This
required some changes to the builds and build_status tables, as for example,
the Cuirass build id may not be available, and the derivation may not be know
yet, so just record the derivation file name.
The intent with these tokens is for them to be provided when build events are
submitted, preventing unauthorised submission of build events.
It should be possible to make the database public, so it shouldn't contain any
secret information. To have secret tokens that aren't in the database, store a
token seed, and combine this with some secret data to compute the secret.
Flip the inequality and order, as this was picking the first revision after
the datetime, rather than the last revision before it, which was the
intention, as this should give you the revision on the branch, at the
datetime.
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.
