更新紀錄

Self-hosted Tuist instances can now automatically clean up artifact files from object storage. Operators can set independent retention windows for cache artifacts, app previews, build archives, run artifacts, test attachments, and shard bundles.

Configure the windows through the Helm chart:

server:
  artifactRetentionDays:
    cacheArtifacts: 30
    appPreviews: 30
    buildArchives: 60
    runArtifacts: 30
    testAttachments: 30
    shardBundles: 14

Each artifact family also has its own environment variable for deployments that do not use Helm. Leaving a family unset or blank keeps its cleanup disabled. Cleanup removes artifact files only and preserves the associated PostgreSQL and ClickHouse metadata used by dashboards and analytics.

Build and test run pages now show a CI Details card whenever Tuist can match the insight to a Tuist Runner job. The card includes the workflow, job, runner profile, queue time, CI job duration, and the exact step that produced the build or test insight.

Runner job details now connect the CI run with the build and test insight data it produced. The new Insights card sits between the job summary and machine metrics, so you can see the build, test, cache, and selective-testing context before diving into CPU, memory, network, or step logs.

Tuist Runner jobs on macOS now include an Interactive tab while the job is running. Open it to see the live runner desktop over VNC, click through macOS prompts, inspect simulator state, or debug anything that is easier to understand visually than from logs alone.

Organization invitations now show whether they are still pending or have expired, so admins can tell at a glance when an invite link is no longer usable. Expired invitations stay visible in the Invitations tab with an Expired status instead of looking active.

You can also resend any invitation from the same row. Resending refreshes the invite link and validity window, making it easier to recover from missed or stale invitations without revoking and recreating the invite.

Teams can now choose who is allowed to upload cache artifacts from the account Cache page. Keep uploads open to members, CI, and account tokens, or switch to CI and account tokens only so developers can keep downloading trusted cache artifacts without publishing local branch builds back into the cache.

This is useful when CI is your trusted cache producer. CI OIDC logins and scoped account tokens can write to the cache, while members using normal login sessions stay read-only. That helps teams avoid one-off local uploads, reduce cache storage growth, and remove upload wait time from developer machines.

A failed test run doesn't always mean a test failed. Sometimes a target's .xctest bundle won't load, or the app under test never launches, so the tests never get to run at all. Xcode treats these as errors rather than test failures, and now Tuist does too: run and target-level errors show up in a dedicated Errors section on the test run page, each with the target that hit it and the underlying message.

Pulling these out of your test cases keeps your counts honest, an error is no longer miscounted as a failed test, and makes the two kinds of problem easy to tell apart. We also renamed the failures section to Test Failures, so each reads as what it is: Errors stopped your tests from running, Test Failures are the assertions that didn't hold.

Your module cache hit rate tells you how many modules you skipped rebuilding. It never told you how much data that cache actually moved, or how quickly. Now it does.

Every run's Module Cache tab surfaces the network side of your cache. Alongside cache hits, misses, and hit rate, you'll now see:

• Downloaded and Uploaded: the total size of prebuilt modules the run pulled from and pushed to the remote cache.
• Download throughput and Upload throughput: how fast those transfers actually moved, as a time-weighted average.

Every job that runs on Tuist Runners now records how hard its machine worked. CPU, memory, network, CPU I/O wait, and storage are captured for the full duration of the run and plotted on the job page, so you can stop guessing whether a build is CPU-bound, starved for memory, or filling up the disk.

Use it to right-size your runner profiles: move a job that barely touches the CPU onto a smaller machine, or give a job pinned at 100% more cores so it ships faster. Hover a step and the charts highlight that window, so you can tell which step pinned the CPU or filled the disk.

Tuist uses your project's default branch as the baseline for analytics, insights, and comparisons, from bundle size checks to test reliability and flaky test detection. It was already configurable through the CLI, and now you can view and change it directly from your project's settings too. When you connect a GitHub repository, Tuist also adopts the repository's default branch automatically.