v2.85.0

Binaries and the merged-pull-request list are on the GitHub releases page.

A job's log keeps pace with its steps

v2.83.0 sent a step's start, its output every 2 seconds and its end, each as its own request, and a job's requests went one after another. On a busy run the log fell behind the job: the first full verify of orun-cloud on v2.84.0 printed log … still uploading as it completes for every job of a lane, each 15 seconds after the job ended, and the lane then spent 50 seconds sending what was left when it finished. A job read finished on Orunbase with a third of its log stored (orun-cloud saas-live-runs LR8b).

Now a job's worker sends whatever is queued for the job in one request. When the uploads keep up, that is one chunk, as before; when they fall behind, the next request carries everything that waited, so the job catches up in a round trip or two however far it fell behind. The final flush at the end of a run, and the drain of a spill file after an outage, send one request per job instead of one per chunk.

• Each chunk keeps its own step coordinate and its place in the job's log; only the number of requests changes.
• A request carries at most 64 chunks and 1 MiB of content, the server's bounds; a larger backlog goes in as many requests as it takes.
• When the server stores part of a request and fails, it says how many it stored, and only the rest is sent again.

Compatibility

• The batched append is POST …/logs/{jobId} with entries, which Orunbase takes from this release's server side on. A server without it refuses the first batch; orun then sends that run's chunks one by one, exactly as v2.84.0 did.
• A spill file written by an earlier release drains as before.
• Local runs and orun logs are unchanged.