| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
PostgreSQL seems to be unhappy with some data, I guess because it gets a bit
jumbled. Rather than failing the job, or getting stuck not inserting logs, try
and capture the error, log the details, and then keep going.
|
| |
|
|
|
|
|
| |
The derivations for channel instances (guix pull) and system tests are now
captured.
|
| |
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
|
|
|
| |
This recent change simply didn't work, the ordering was bad and the window
function wasn't properly defined. It now should hopefully work, although
there's an interesting case where different versions are available for
different systems/targets, which isn't handled particularly well.
|
|
|
|
|
|
| |
This is better than just deleting the entries that don't match up with the
remaining revisions, but also not very useful for local development (due to
the lack of data).
|
|
|
|
|
| |
Somewhat untested improvements, but these make the query a bit more rigorous
in the case of multiple branches and git repositories.
|
|
|
|
|
|
| |
Previously, the select option label was empty that's not particularly
informative. These changes also fix the next page link behaviour for the
target parameter.
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
| |
|
|
|
|
|
|
|
|
| |
Actually check if fields can be NULL, and if they can be then include some
extra conditions for the comparison.
This will at least make the queries smaller, I'm not sure if it will have an
effect on performance.
|
|
|
|
| |
Mostly so whether a field can contain NULL values can be determined.
|
|
|
|
|
| |
Given that a commit, regardless of what repository it comes from should
contain the same exactly the same data, just track jobs by commit.
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
| |
In the hope that this makes the script faster.
|
|
|
|
|
| |
In the create-small-backup script, as this is quite a slow part, it's useful
to get more information.
|
|
|
|
|
| |
derivation_output_details_sets, and derivations_by_output_details_set. This
required moving around some of the code.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Hopefully this will help with the pg_restore in the create-small-backup
script:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2875; 0 0 COMMENT EXTENSION plpgsql
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql
Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
|
|
|
|
| |
This greatly improves the performance of the derivation-outputs page.
|
|
|
|
| |
Otherwise this table is empty.
|
|
|
|
| |
Otherwise this table is empty.
|
|
|
|
| |
This was redundant and slow, so don't do it.
|
|
|
|
|
|
| |
The derivation checker currently opens a store connection on its own, but by
passing the already open connection in, it won't have to do that, and
hopefully this will make checking all the packages faster.
|
|
|
|
| |
It's been replaced by the package_derivations_by_guix_revision_range table.
|
|
|
|
|
|
|
|
|
| |
Rather than having two big tables looking at the history, just use the
derivations table as it has all the information.
This will allow deleting the package_versions_by_guix_revision_range table
which should help save time when importing revisions, and reduce the size of
the database.
|
| |
|
|
|
|
|
| |
This might solve errors where the Guix Data Service is trying to insert a
lint_warning_message_set that already exists.
|
|
|
|
| |
Rather than having an empty table.
|
|
|
|
| |
Put the non-cross built derivations first.
|
|
|
|
|
|
|
| |
This complements the existing pages for the version history, and derivation
history. As well as the new page, the buttons and styling of the two existing
pages has been made to match better to enable easier navigation between the
pages.
|
|
|
|
|
| |
Similar to the one above for derivations, this just looks at outputs. This
filters out equivalent derivations, which can be useful.
|
| |
|
|
|
|
|
| |
These parts of the backup scripts are optional, so don't fail if they don't
work.
|
|
|
|
|
|
|
| |
Rather than just the native system. I'm not quite sure of the value here, as I
guess system tests should behave the same regardless of the way the software
is compiled, but this seems like it could be useful, and being explicit about
the system the derivation is for is good.
|
|
|
|
|
| |
The switch away from catch broke this, I obviously still don't quite get how
with-exception-handler works. Therefore, use it twice as that seems to help.
|
|
|
|
| |
Move it after the output relating to narinfo signing, and include the host.
|
|
|
|
| |
As this could be a common problem.
|
|
|
|
| |
Render some HTML rather than the plain response.
|
|
|
|
|
| |
Adjust the previously unused error page code, and start to use it. Only show
the error if configured to do so, to avoid leaking secret information.
|
|
|
|
|
| |
To increase the likelyhood that all the builds and narinfo files for the
latest revisions are fetched.
|
|
|
|
| |
Pulling out the recent entries first.
|
|
|
|
| |
As it makes it clearer what tables will be truncated.
|
| |
|
| |
|
|
|
|
|
| |
Rather than looking for the oldest unknown outputs, as the new ones are
generally more useful.
|
| |
|