| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Through the command line interface.
|
| |
|
|
| |
processed, within this record is now a boolean.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Because some of the module inputs write output.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
More clearly split out the things that need to happen prior to run-fibers, and
the things that can happen after.
|
| | |
|
| | |
|
| |
|
|
| |
By default. This avoids issues when sqitch is run with --chdir.
|
| | |
|
| |
|
|
| |
Which was extracted from the Guix Build Coordinator.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will allow some parallel processing of hook events, at least those of
different types.
|
| |
|
|
|
| |
This is useful to find builds that have failed, and in failing blocked other
builds from being attempted.
|
| |
|
|
| |
As I'm guessing this could block the thread for fibers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There were a few issues with the previous approach, I was concerned about
trying to write to the SQLite database from two processes, it's already
segfaulting occasionally when accessing it from just one. Additionally, the
client actions were already doing things that should happen in the coordinator
process, like allocating builds.
I'm trying to not turn this in to a web app, but not doing very well. Although
having this information and these actions available over the network does make
it possible to build a web app frontend, which I've had in mind.
|
| | |
|
| |
|
|
|
| |
Associate this with the coordinator, rather than having the logic in the agent
communication code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm looking to listen for client instructions ("build this", ...) maybe on a
UNIX socket, which looks to be possible with fibers, but doing this at the
same time as using a network socket for agent messaging requires more access
than run-server from the fibers web server module currently allows.
To get around this, patch the fibers web server run-server procedure to do
less, and do that instead in the guix-build-coordinator. This is somewhat
similar to what I think Cuirass does to allow it to do more with fibers.
This required messing with the current-fiber parameter in a couple more places
around threads, I'm not really sure why that problem has occurred now. This
current-fiber parameter issue should be resolved in the next fibers release.
One good thing with these changes is some behaviours not related to agent
communication, like triggering build allocation on startup have been moved out
of the agent communication code.
|
| |
|
|
|
|
|
| |
To make it clear this is what it's for. This makes it easier to allow other
ways of communicating with agent processes in the future, as well as making it
easier to set out how to also listen for client commands, which I'm thinking
about now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This was resulting in duplicate builds for the same output, as that's not what
it was guarding against, but I think that was my intention... Anyway this
should actually only result in builds being created for outputs that are
required.
|
| |
|
|
| |
This was broken with the API change to the coordinator.
|
| | |
|
| |
|
|
|
| |
This is already useful to pass around the datastore, hooks and metrics
registry, and will become more useful to pass around the allocator to use.
|
| | |
|
| |
|
|
|
| |
It will show the builds for the output. This commit also adds more information
in to the output.
|
| |
|
|
| |
A way of getting information out about a build.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Allow specifying build priority, although the allocator currently doesn't use
this. Add --defer-allocation to allow inserting lots of builds without
spending time re-computing the allocation for each one. Add
--ensure-all-related-derivations-have-builds to make it easy to have a
derivation, and all related derivations built at least once. Add
--ignore-if-build-for-derivation-exists to make it easy to avoid building
derivations again if that isn't the intention.
|
| |
|
|
|
|
|
| |
That submits new build jobs to build these missing inputs if appropriate.
This means that you can tell the coordinator to build something, and it will
automatically attempt to build the dependencies if they're missing.
|
| |
|
|
| |
This allows configurable code to be executed when builds succeed or fail.
|
| | |
|
| |
|
|
|
| |
This should support generating the passwords off the value stored in the
database, and the secret key base value, but that can be implemented later.
|