Cuirass provides a timestamp field in build responses, and sometimes this
means when the build was scheduled, but when the build is finished, it's the
stoptime.
So only use the timestamp when the build hasn't finished.
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.
