| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
It can be #f if no agent is allocated the build.
|
| |
|
|
|
| |
Previously SIGPIPE killed the agent. This should avoid that and have the agent
retry.
|
| |
|
|
|
| |
Start writing a proper Prometheus client, hopefully this code can be extracted
at some point.
|
| |
|
|
| |
This should make agent <-> coordinator communication more failure tolerant.
|
| | |
|
| | |
|
| |
|
|
| |
To reduce the code duplication.
|
| |
|
|
| |
The reasoning changed with 9acc42cfd1d081ca1e8d8aa41fe0eb20303e5df3.
|
| |
|
|
|
|
|
|
|
| |
blocking""
Fibers gets upset when trying to upload files: Attempt to suspend fiber within
continuation barrier, so try doing this in a thread.
This reverts commit 63b0fa9c37a5cd540bcbb975598baa8ef1a3831b.
|
| |
|
|
|
|
| |
The non-fibers one processes requests sequentially, which just won't do.
This reverts commit 2d2ae5b6b01081f35ad2fc25affdef8c876b48e6.
|
| |
|
|
|
|
|
| |
This didn't help, as I think the web server just processes requests
sequentially. Hopefully once that's resolved, this won't be necessary.
This reverts commit 48ed0eead59119c269993dbfa2c9ca8302b52d3d.
|
| |
|
|
| |
Present on the coordinator.
|
| |
|
|
|
| |
Not sure if this'll work, but hopefully offloading reading the chunked
requests to other threads will avoid blocking.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From looking at what curl does, it seems that the last the requests end in
"0\r\n\r\n". The requests being sent before just had "0\r\n" at the end. This
worked with the server, because that wasn't expecting the final "\r\n", and it
would crash if it was included, as it would be read as the start of the next
request.
To work around this, adjust both the sending and receiving of the
requests. Send the "\r\n" after the chuncked data when making requests, and
use a patched version of make-chunked-input-port that requests two more bytes
after it's finished reading the last chunk.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The put-message operation blocks, which doesn't work for triggering the
allocation process.
|
| |
|
|
| |
This might help with using fibers for other things.
|
| |
|
|
| |
This allows configurable code to be executed when builds succeed or fail.
|
| |
|
|
|
|
|
|
|
| |
Move some of the code around, and trigger allocating builds via a thread if an
agent fails to setup for a build and when a build succeeds/fails.
This is important, as some setup failures can be handled by the build
allocator, for example a build finishing may unblock other builds waiting for
outputs it generates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
There's some support for using the chunked transfer encoding, but only for
response bodies.
Rather than returning a bytevector, return a port so that the data can be sent
to a file, rather than having to store it all in memory first.
|
| |
|
|
|
| |
I'm not sure how to get requests with chunked bodies working with the fibers
server.
|
| |
|
|
|
| |
This makes it possible for an agent to find out what builds it's been
allocated, if any.
|
| | |
|
| | |
|
| | |
|
| |
|