| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
The default value of the current system can lead to duplicates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also support fetching builds for specific systems from the Guix Data Service.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
In the queue builds script.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
When submitting builds.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The agent looks to substitute the derivation, and also substitute inputs, so
allow providing different substitute URLs for each of these purposes. This can
make substituting faster in the case where you have a different source of
substitutes for derivations and non-derivation items.
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
So that you don't have to just use the daemon's defaults.
|
| |
|
|
| |
As that is an easy way to find things to 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.
|
| | |
|