aboutsummaryrefslogtreecommitdiff
path: root/sqitch
Commit message (Collapse)AuthorAge
* Don't hardcode the expected x-git-repo header valueChristopher Baines2020-01-11
| | | | | Rather than expecting it always to be "guix", store the expected value in the database, and use the value of the header to find the relevant repository.
* Add a table to configure which build servers build whatChristopher Baines2020-01-05
|
* Create an index on the hash component of the store pathChristopher Baines2019-12-29
| | | | For derivation_source_files.
* Add a new table to nars for derivation source filesChristopher Baines2019-12-28
| | | | This will allow serving the nars for derivation source files.
* Create an index for the hash component of derivation filenamesChristopher Baines2019-12-26
| | | | | | This is to aid rendering of narinfo files. They're requested with the path /HASH.narinfo, so to quickly find the relevant derivation, this index can be used.
* Add new derivation_output_details_set_id column to the builds tableChristopher Baines2019-12-12
| | | | | As this will hopefully provide a faster way of associating derivations with builds.
* Start storing and identifying sets of derivation outputsChristopher Baines2019-12-12
| | | | | | | | | | | Derivations are effectively equivalent if they produce the same set of outputs, which is possible because of the equivalence of fixed output derivations. A fixed output derivation can be different, but equivalent, because it produces the same fixed output. To better allow tracking equivalent derivations, primarily to allow working out what derivations might correspond to a build, store the sets of derivation outputs, and which derivations they relate to.
* Add some database indexesChristopher Baines2019-12-12
|
* Deduplicate builds and add a unique indexChristopher Baines2019-12-12
| | | | | | | Duplicate builds could creep in if the code to create them ran concurrently. I didn't exclude them initially, as I was unsure if there should be such a restriction, but at least for now, Cuirass builds map exactly to a single derivation, so use the same restriction here.
* Change nar_urls size to bigintChristopher Baines2019-12-12
| | | | As some nars can be bigger than the size of an int.
* Change nars size to bigintChristopher Baines2019-12-12
| | | | As some nars can be bigger than the maximum size of an int.
* Add a table to record where narinfo files were fetched fromChristopher Baines2019-12-12
| | | | Otherwise it's hard to associated narinfo files to build servers.
* Add an index on the derivation_file_name field in the builds tableChristopher Baines2019-12-12
| | | | As this helps when finding builds relating to specific derivations.
* Begin to add support for importing narinfo filesChristopher Baines2019-11-30
| | | | | This commit adds the tables, as well as code to support extracting data from narinfo files.
* Rework the builds and build_status tables as well as related codeChristopher Baines2019-11-24
| | | | | | | 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.
* Add new table to store token seeds for build serversChristopher Baines2019-11-23
|
* Add a new channel-news module, along with tables the relevant dataChristopher Baines2019-11-21
|
* Add a new table to describe the history of derivationsChristopher Baines2019-11-09
| | | | | 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.
* Remove duplicates from the guix_revisions tableChristopher Baines2019-10-05
|
* Make it easier to retry jobsChristopher Baines2019-10-02
| | | | | | | | Add a new event 'retry', and run jobs where the number of retry events is greater or equal to the number of failure events. Also add an index to the git_branches table to make the finding jobs query a bit faster.
* Fix the 'NULL' values in git_branches for the commitsChristopher Baines2019-09-29
| | | | | | | | | | | The git_branches table had 'NULL' values for some commits where the branch was deleted, importantly this was the string 'NULL', not an actual NULL value. This commit fixes that, migrating the existing values to be '', and changing the relevant code. The primary key is also extended to include the datetime field, as this is important to allow a branch to be deleted twice.
* Add migration to create an index on load_new_guix_revision_job_eventsChristopher Baines2019-09-29
| | | | To speed up the rendering of the index page.
* Add a new table to store package versions by revision rangesChristopher Baines2019-09-27
| | | | | | | This isn't new information, but derived from information already in the database. It's collected here to make querying faster. The table is updated when each new revision is entered.
* Add a new table guix_revision_lint_checkersChristopher Baines2019-09-01
| | | | | | | | | To associate a set of lint checkers with a specific revision. While there is the association through the lint warnings, that only works for checkers where there are lint warnings for that revision. Therefore, to allow finding all the checkers for a specific revision, also associate them directly with the revision.
* Store lint warnings in the databaseChristopher Baines2019-09-01
| | | | | | | | | | This commit adds the relevant tables and code to store lint warnings in the database. Currently, only lint checkers which don't require access to the network will be run, as this allows the processing to happen without network access. Also, this functionality won't work in older versions of Guix which don't expose the lint warnings in a compatible way.
* Avoid erroring when processing emails againChristopher Baines2019-08-05
| | | | | These changes allow processing emails again, and just creating job and branch entries where data is missing.
* Change the git_branches table primary keyChristopher Baines2019-08-05
| | | | To allow for having branches in multiple git repositories.
* Fix some duplicated values in tablesChristopher Baines2019-08-04
| | | | | | | | | | | | | The licenses table, along with the package_metadata table had duplicate values. This could happen as the unique constraints on those tables didn't properly account for the nullable fields. The duplicates in those tables also affected the license_sets, packages, package_derivations tables in a similar way. Finally, the guix_revision_package_derivations table was also affected. This commit adds a migration to fix the data, as well as the constraints. THe code to populate the licenses and package_metadata tables is also updated.
* Tweak how logs are storedChristopher Baines2019-07-07
| | | | | | | | | | | | | | | | | | Previously, the query for the jobs page was really slow, as it checked the load_new_guix_revision_job_log_parts table for each job, doing a sequential scan through the potentially large table. Adding an index didn't seem to help, as the query planner would belive the query could return loads of rows, where actually, all that needed checking is whether a single row existed with a given job_id. To avoid adding the index to the load_new_guix_revision_job_log_parts table, and fighting with the query planner, this commit changes the load_new_guix_revision_job_logs table to include a blank entry for jobs which are currently being processed. This is inserted at the start of the job, and then updated at the end to combine and replace all the parts. This all means that the jobs page should render quickly now.
* Record the output from loading new revisions to the databaseChristopher Baines2019-06-22
| | | | | | | So that it can easily be shown through the web interface. There's two tables being used. One which temporarily stores the output as it's output while the job is running, and other which stores the whole log once the job has finished.
* Add more detailed new revision job handlingChristopher Baines2019-06-02
| | | | | | | | Create a new events table for the new guix revision jobs, and update this when processing a job starts, as well as finished with success or failure. Additionally, remove the dependnency on open-inferior/container, as this functionality isn't merged in to Guix master yet.
* Record job success without deleting the job recordChristopher Baines2019-06-02
| | | | | | | Previously, the records for jobs would be deleted. It's useful to know when jobs were inserted in to the database, as well as when they succeeded (if they have). This change also makes it possible to keep track of jobs that have failed, as they won't be deleted.
* Store license information for packagesChristopher Baines2019-05-15
| | | | | | | | | | And display this on the package page. This uses a couple of new tables, and an additional field in the package_metadata table. Currently, the order of the licenses in the package definition isn't stored, as I'm not sure the order in the list is significant.
* Store and display the location of packagesChristopher Baines2019-05-13
| | | | | | | 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.
* Remove the sha1_hash from the package_metadata tableChristopher Baines2019-05-12
| | | | | | | | I'm thinking about adding more fields to this table, and the sha1_hash values will make this tricker. Therefore, remove the value, and adjust the existing code to cope. This commit also adds a new test which coveres some of the changed functionality.
* Start to handle information about Git branchesChristopher Baines2019-05-05
| | | | | | 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.
* Switch to storing Git repositories in a tableChristopher Baines2019-05-05
| | | | | | 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.
* Add some initial Sqitch migrationsChristopher Baines2019-04-14
| | | | These are based on the state of the current manually managed database.
* Move the sqitch files in to the sqitch directoryChristopher Baines2019-04-13
To keep them together, and leave the top level repository directory clearer.
generated by cgit v1.2.3 (git 2.45.0) at 2024-11-21 23:58:09 +0000