| Commit message (Collapse) | Author | Age |
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some exceptions raised in worker threads, seemingly those that come from
guile-sqlite3, Guile can't print the backtrace without erroring itself [1].
Work around Guile not being helpful by just printing out the backtrace, that
Guile may fail to print, after the details of the exception. At least then
there's something informative in the output.
1: In procedure string->number: Wrong type argument in position 1 (expecting
string): #f
|
|
|
|
| |
Remove one layer of exception handling, as I don't think it was adding much.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Which was extracted from the Guix Build Coordinator.
|
|
|
|
| |
Rather than the lzlib module within Guix.
|
|
|
|
|
| |
Keep a connection open for longer, to allow for doing things like registering
gc roots.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As this information will come in useful when working out how to handle builds
for fixed output derivations. Specifically, I want to make it configurable
whether to add builds for fixed output derivations if a build already exists
for the output, but the derivation is different.
Currently, different fixed output derivations can be ignored but it's not
possible to just avoid adding more builds for non fixed output derivations
while adding builds when fixed output derivations change. This new information
will help enable that.
|
|
|
|
|
| |
Because items can be in the store but not be valid. This should help with
issues where the build can't start, but all the items show up in the store.
|
|
|
|
|
|
|
| |
Previously builds were only considered if for the derivation, all the inputs
had successful builds. However, this only accounted for inputs directly
matching the derivation, not other derivations that also provided the same
output. This commit fixes that.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Previously, some builds where skipped for things like fixed output
derivations. If a aarch64-linux build already existed, the x86_64-linux build
for the same output wouldn't be created. This has delayed some builds, because
they're unnecessarily waiting.
|
| |
|
| |
|
|
|
|
|
| |
So that this information can be used by the allocator. Because that's
expected, also trigger allocating builds if the systems for an agent changes.
|
| |
|
|
|
|
|
| |
This can then be used by allocators to avoid allocating builds to agents that
they're never going to fetch.
|