tuistdev

Organizations had two roles, admin and user, and both could act on what they saw. Muting a flaky test, deleting a preview, writing to the cache: a user could do all of it. Opening your build and test insights to the wider engineering team meant handing ev

macOS runner profiles have offered a single machine shape since launch: 6 vCPU / 14 GB. There is now a second, 12 vCPU / 28 GB, running on M4 Pro hardware. Pick it when you create or edit a macOS profile. The 6 vCPU shape stays the default, and existing p

Reliability automations used to measure every run of a test, whichever branch it came from, so uploading pre-commit results meant letting work-in-progress failures move the number that decides whether a test gets quarantined. They now measure runs on your

At first, a build looks simple. Change a file, run a command, and a compiler turns the source into something you can ship or test. On a small project, that is close enough to the whole story. The machine has work to do, it does it, and a few moments later

When a pull request pushes your app past a size threshold, Tuist fails the tuist/bundle-size check run and puts an Accept button on it, so an increase you meant to make does not need a second commit to get through. Until now anyone with write access to th

Project automation settings now include a configuration history. Each entry shows who made the change, when it happened, the fields that changed, and the previous and new values. The latest five changes are shown first, with Show more available when an au

The test case page reported four numbers for the window you picked: how many times the test ran, how often it flaked, how reliable it was, and how long it took. Each one told you where the test stands. None of them told you how it got there, which is the

The Test Cases table showed one duration per test: the mean of its last 50 runs, with no time bound and no separation between CI and local. A single stalled run, a paused debugger for example, stayed in that average until 50 newer runs pushed it out, and

The summary metrics on a test case page now respond to a date range picker, with presets for the last 24 hours, 7 days, 30 days and 12 months, plus a custom range. The selection lives in the URL, so a link to a test case carries the window you were lookin

The quarantined tests page now shows a sortable "Quarantined at" column, and the flaky tests page a "Marked flaky at" column. Both timestamps come from the test's event history and reflect when the test entered its current state - re-quarantining a test s