| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Until actually storing the build, since the build might not actually be
submitted if there's a build for those outputs already.
|
|
|
|
|
| |
Don't keep database connections around forever as this relates to cached query
plans, and also run the optimize pragma when closing connections.
|
|
|
|
| |
It's important that this code doesn't run until Sqitch has run.
|
|
|
|
|
|
| |
This avoids the need to create agents upfront, which could be useful when
creating many childhurd VMs or using scheduling tools to dynamically run
agents.
|
| |
|
|
|
|
|
| |
This should make it possible to check properly whether the outputs are needed,
instead of just assuming they are not if there's been a successful build.
|
|
|
|
|
| |
This might not be helpful, but I think it's still worth trying, even if all
the line numbers are within Guile itself...
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With with-exception-handler being called with #:unwind? #f (implicitly). This
breaks Guile internals used by (backtrace) [1], meaning you get a different
exception/backtrace when Guile itself breaks.
This should avoid the "string->number: Wrong type argument in position
1 (expecting string): #f" exception I've been haunted by for the last year.
1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46009
|
| |
|
|
|
|
| |
This is often unnecessary if the outputs have already been built.
|
|
|
|
|
| |
And out of the datastore. This means that datastore code doesn't have too much
logic in it.
|
|
|
|
|
| |
And in to the coordinator module. This will make adding more datastore's
easier.
|
|
|
|
| |
As this code should be in the coordinator.
|
|
|
|
| |
My refactoring went quite wrong.
|
|
|
|
|
|
|
|
|
| |
This isn't intended as some time based scheduling, but more as a way to slow
down builds by deferring processing them until some point in the future.
I'm intending to use this to test fixed output derivations. I can look up all
the derivations I want to test, then defer the builds to run spread out across
some period. This feature saves having to submit the builds gradually.
|
|
|
|
|
|
| |
Don't include canceled builds in the build-for-derivation-exists? or
build-for-output-already-exists? options. I think it makes sense to not
include canceled builds in these options.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Originally I was trying to keep the implementation details of the datastore in
the datastore modules, but this approach starts to crack as you cope with more
and more complicated transactions.
This change should help resolve issues around getting the coordinator logic in
to the coordinator module, and simplifying the SQLite datastore in preparation
for adding PostgreSQL support.
|
|
|
|
| |
For some consistency.
|
| |
|
| |
|
|
|
|
| |
As the allocator currently can take much longer than 10 seconds.
|
| |
|
|
|
|
|
|
|
| |
Some parts of this were quite slow with anything other than a small database,
so instead of doing slow queries on every request, do some slow queries to
setup the metrics, and then change them as part of the regular changes to the
database.
|
|
|
|
| |
Just join against the database table, rather than using the values.
|
|
|
|
|
| |
SQLite's usual approach doesn't seem to always contain the size of the WAL, so
move this logic in to the application and regularly run a checkpoint.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, an agent could end up fetching builds from the coordinator, but
not receiving the response, say because of a network issue or timeout. When it
retries, it would fetch even more builds, and there would be some allocated to
it, but that it doesn't know about.
These changes attempt to make fetching builds more idempotent, rather than
returning the new allocated builds, it returns all the builds, and rather than
requesting a number of new builds, it's the total number of allocated builds
that is specified.
|
|
|
|
|
| |
This seems like sensible behaviour, but it might be good to make this optional
in the future.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Things like the agent not having the log file, or an output. This will allow
the agent to actually retry the relevant thing.
|
| |
|
|
|
|
| |
This matches a change in the guile prometheus library.
|
|
|
|
| |
Make more of an effort to ignore the .tmp files.
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
|
| |
This is moving in the direction of not having to use the script to start the
service. I think for a Guix service definition, being able to specify some
Guile code directly will be better.
|