Wiring the runner to the build, and gating the cache
A week that joined CI runs to the build and test data they produced, opened a live macOS desktop into running jobs, and added governance for who writes to the cache and how long self-hosted artifacts live.
Wiring the runner to the build, and gating the cache
This week Tuist tightened the relationship between a runner job and the build or test insight it produced, opened a live window into running macOS jobs, and added two governance levers for the artifacts that pile up around both.
The most striking pair of changes lands on either side of the same question: when something in a build looks off, how quickly can you find the CI run that caused it? On the runner side, job details now carry an Insights card sitting between the summary and the machine metrics, so build, test, cache, and selective-testing context appears before you reach the CPU, memory, and network charts (Insights in runner jobs). On the insights side, build and test run pages now carry a CI Details card whenever Tuist can match the run to a runner job, including the workflow, job, runner profile, queue time, CI job duration, and the exact step that produced the insight (CI details on build and test runs). Read together, these are a deliberate round trip: a failing test now links forward to the runner job, and that job links back to the build and test summaries that flagged it. The product is quietly replacing the usual hop from “what broke” to “which CI run did this” with a direct edge in the UI.
The other runner change is harder to summarize and easier to feel. macOS runner jobs now expose an Interactive tab while they are running, streaming the desktop over VNC so you can click through macOS prompts, inspect the simulator, or chase a visual failure without re-running the job locally (Interactive access for macOS runner jobs). For iOS teams, this closes a long-standing gap: many Xcode and simulator failures only make sense when you can see the screen, and until now that meant either reproducing locally or attaching screenshots to a bug. A live VNC session keeps the runner authoritative while making the debugging loop feel local.
Two more changes share a quieter theme of letting operators decide what stays and who gets to write.
Cache upload access now ships a per-account setting that can switch uploads to CI and account tokens only, while member sessions stay read-only (Cache upload access controls). The framing is specific: when CI is the trusted cache producer, you can let OIDC logins and scoped account tokens keep populating the cache without letting local branch builds publish back into it. That is a real cost and noise control, not just a permission toggle, and it acknowledges that developer machines are usually cache consumers, not producers.
Self-hosted deployments got a parallel lever. Artifact retention is now configurable per artifact type, covering cache artifacts, app previews, build archives, run artifacts, test attachments, and shard bundles, all set through the Helm chart (Configurable self-hosted artifact retention). The point is to stop object storage from growing without bound in installations that run their own CI fleet.
What ties the week together is a steady shift from “more data on the page” to “data that knows where it came from and who is allowed to add to it.” The runner, the insights, the cache, and the storage bucket are increasingly pointing at each other instead of living as separate tools. For self-hosted operators the implication is concrete: expect more surfaces like retention and upload policy to become first-class configuration, and plan for an audit trail that can answer which CI job produced which artifact and why it is still there.
Narrated from 5 public drops.