Replace the Guile-side HTML escaping with a less complete, but hopefully
faster PostgreSQL side HTML escaping approach.
Also, allow reading part of the log, by default, the last 1,000,000
characters, as this should render quickly.
To the compare/derivations page. Previously, the compare/derivations page was
comparing more than the derivations, notably the package metadata. This change
avoids that, and also reduces the information overload on the compare page.
So that they can also be used for the /branch/foo/latest-processed-revision
pages. The content is the same, but the title, link, and some of the links on
the page are different.
This makes is easier to get the latest data for a branch in a single request,
rather than making one request to find the latest revision, then another to
get the data.
This indicates currently if the database is accessible and a simple query can
be performed. I'm mostly looking at using this when writing a system test for
this service.
Previously, one of the first things that happened when responding to a request
was a database connection was made, even when serving the CSS. This is
unnecessary, so move the database connection handling in to the controller.
Also, to allow for separating it out from the assets, separate the assets out
from the parts of the controller that require a database connection.
Given that the headers may be the same, regardless whether it's HTML or JSON
being sent in the body of the response, I think it makes more sense to handle
the headers in the controller.
Store the location a package can be found at, and display this on the package
page.
If available, link off to the git repository containing the package.
Previously, the routing layer handled the content negotiation, and the Accept
header was ignored. Now, the extension if one is provided in the URL is still
used, and more widely than before, but the Accept header is also taken in to
account.
This all now happens before the routing decisions are made, so the routing is
now pretty much extension independant (with the exception of the
/gnu/store/... routes).
The query parameters feed in to the results shown, but also forms on
pages. Validation is important to avoid errors and security issues, but it's
also important to provide appropriate feedback to the user.
This module provides some utilities and structure around handling query
parameters.
Add some new pages /branches and /branch/... as well as a new git_branches
table. Also extend the email processing to enter the branch information in to
the database.
Rather than just storing the URL in the guix_revisions and
load_new_guix_revision_jobs tables. This will help when storing more
information like tags and branches in the future.
