| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
I do not understand why, but I think the removal of the "redundant" reset
statements has broken the database in some way I haven't been able to pin
down. Either writes aren't working, or some reads are returning stale
data. I'm also seeing errors about locked tables :(
This reverts commit 049334e423241426c0eef526eda8818e96f5b3ca.
|
|
|
|
|
| |
Previously, the derivation system was ignored, but this now takes it in to
account. The implementation is copied from the derivation ordered allocator.
|
| |
|
|
|
|
|
| |
Which is most of them. Not sure why I started resetting statements after their
use, but it's unnecessary.
|
| |
|
| |
|
|
|
|
|
| |
Rather than polling the database every second, use some condition variables to
wake threads when there's probably an event.
|
|
|
|
| |
This might help work out why it gets stuck.
|
| |
|
|
|
|
|
| |
Just for the request processing at the moment, but with a plan for more things
in the future.
|
| |
|
| |
|
|
|
|
|
|
| |
Use a temporary table to avoid computing the priorities for all builds. This
speeds up the allocation to only take a few seconds on the database I'm
testing against.
|
| |
|
|
|
|
| |
As this speeds the query up substantially.
|
|
|
|
|
|
|
| |
One of the slow things in the derivation ordered allocator is working out what
outputs are unbuilt, as this requires looking at all the derivation
outputs (of which there are lots), and checking if any build exists which has
succeeded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Guix Build Coordinator would segfault, and this seemed to come when
preparing statements. I think this is happening because the (sqlite3) bindings
finalize statements when they're out of scope, and this happens in the garbage
collector thread. SQLite is running in multi-threaded mode, which means
actions relating to one database connection shouldn't happen concurrently in
different threads, hence I think this is leading to a segfault.
To work around this behaviour, pass #:cache? #t to sqlite-prepare so
statements are long lived where possible, or in the few cases where the SQL is
dynamic, make sure to finalize it before the garbage collector gets a chance.
This'll hopefully mean that there's less segfaults...
|
|
|
|
| |
This will help track CPU time, as well as restarts/crashes.
|
|
|
|
| |
In the agent and allocator.
|
| |
|
|
|
|
|
|
| |
For the derivation ordered allocator. This is an quick alternative for having
some kind of archival mechanism for builds. It should reduce the time it takes
the allocator to run.
|
|
|
|
| |
As there's no need to consider unprocessed builds in this part of the query.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Substitutes could be available for all direct inputs, but be missing for
things they reference. This could happen if those builds happened on a machine
with the store items available for example.
Therefore, search the entire graph for the relevant derivation when looking
for the derivation to build to provide the missing input.
This change matches up with the similar improvement around handling fetching
substitutes.
|
|
|
|
|
|
|
|
| |
When a substitute is found for a direct input, but it can't be fetched, this
is probably because something it referenced isn't available. Therefore, look
through the references recursively and collect up the store items that aren't
available locally or via a substitute. Send this list to the coordinator so
that it can schedule builds.
|
| |
|
|
|
|
|
| |
As the file might exist, but ignored because the daemon is treating it as
invalid.
|
|
|
|
|
| |
When submitting builds. The agent will now retry the relevant thing, like
uploading the log file if the coordinator says that still needs doing.
|
|
|
|
|
| |
Things like the agent not having the log file, or an output. This will allow
the agent to actually retry the relevant thing.
|
|
|
|
| |
So that this code can be retried if submitting the build result fails.
|
|
|
|
| |
As this will enable responding to some exceptions at a higher level.
|
| |
|
|
|
|
| |
So that an absolute filename can be used.
|
| |
|
|
|
|
| |
In case you want to use the absolute location of the binary.
|
|
|
|
| |
This matches a change in the guile prometheus library.
|
|
|
|
|
|
| |
So that it'll run only if the narinfo on S3 is changed, because this should
prevent it running when the hook wouldn't change the narinfo on S3, because
one already exists.
|
|
|
|
|
| |
* guix-build-coordinator/client-communication.scm (send-request): Use
coordinator-uri instead of the hard-coded localhost uri.
|
|
|
|
|
| |
To make sure some useful information makes it out, because (backtrace) can
raise an exception.
|
|
|
|
| |
To allow doing things with the nar/narinfo files before they're deleted.
|
|
|
|
| |
Make more of an effort to ignore the .tmp files.
|
| |
|
|
|
|
|
| |
This will be a breaking change for existing deployments, as the old sqitch.db
file will need to be moved manually.
|
| |
|
|
|
|
|
|
| |
build-log-file-location replaces build-log-file-exists? as it doesn't always
return a boolean, it also changes to return an absolute filepath for the log
file if it exists, as this will be easier to use.
|
| |
|
| |
|
| |
|
|
|
|
| |
So that the client part doesn't depend on fibers.
|
|
|
|
|
| |
To start making it possible to use the agent, without having to load anything
related to fibers (as it doesn't work on the hurd yet).
|
|
|
|
|
| |
I don't know if this is happening, but the hooks are getting stuck, and this
might be a cause.
|