Module Cache reported how often the cache was hit, but not which modules were responsible. The new Modules page ranks every module by cache misses, with its hit rate and how many modules have to be rebuilt when it changes.
Each miss carries a reason. Changed means the module's own content moved, upstream means only a dependency did, and cold means there was nothing to compare against. Upstream misses are the ones better module boundaries can remove.
Opening a module adds every build it took part in, filterable by branch, commit SHA or reason, so a high upstream share leads to the commits behind it. Dependents needs the dependency edges newer CLI versions send; everything else works with the data the CLI already reports.
Find it under Module Cache › Modules.
Gradle build details now explain cache work that previously appeared only as a miss. The cache tab distinguishes confirmed remote misses, the time spent executing after those misses, and outputs stored for later builds. Its task table also identifies the reason a cacheable task ran again.
The new Build Setup tab shows configuration work by build, settings, and project phase. When Gradle uses its configuration cache, the tab records whether it was reused and lists invalidation reasons. It also lists the slowest artifact transforms, so dependency setup costs are visible beside task execution.
Existing Gradle integrations remain compatible. Older build reports continue to render normally, while newer plugin versions contribute the additional diagnostics when they are available.
The platform's programmatic interfaces now provide read parity for project configuration, shareable previews, automation alerts and their revision history, notification alert rules, continuous-integration runner activity including job logs, steps, and machine metrics, webhook delivery history, and account and project token metadata. Each operation follows the authorization policy of its platform domain. Token values remain unavailable after their one-time reveal, webhook signing secrets and encrypted automation action credentials are never returned, and webhook delivery data remains restricted to account administrators.
This makes it easier to investigate a project or audit its configuration from an agent without copying identifiers or sensitive token values into a conversation.
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 every one of them the ability to quarantine a test.
Members can now be added as viewers. A viewer reads projects, builds, test runs, previews, bundles, and runner activity, and cannot change any of it. Where a control would mutate something, a viewer sees the current value instead: a muted test case still reads as muted, it just cannot be un-muted from that page.
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 project's default branch. There is nothing to configure: existing alerts pick it up, and send your pre-commit runs to Tuist to get the reports and failure detail while the reliability figure keeps describing your trunk. A test case needs at least ten default-branch runs in the window before an alert acts on it, so a single bad run cannot quarantine anything.
Flakiness automations are unchanged and still measure every branch.
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 automation has older history. This makes it easier to understand why an automation behaves differently while keeping long histories readable.
