Analyze merge queue performance for specific parts of your codebase
Now you can filter merge queue health metrics by impacted targets to see exactly how well this parallel workflow is performing for each part of your codebase. For example, in a TypeScript/Python monorepo, you can view metrics specifically for TypeScript PRs versus Python PRs, identify if one team is experiencing slower merge times than another, and optimize queue configuration for your highest-priority code paths.
This visibility helps you demonstrate the value of parallel mode to engineering leadership, ensure fair queue performance across teams, and make data-driven decisions about how different parts of your codebase move through the merge process and priorities.
Skip redundant testing and merge immediately when your PR is already up-to-date and the queue is empty
The merge queue exists to test your PR against the latest version of main, but if your PR is already based on the tip of main and the queue is empty, rerunning tests provides no additional value; you've already tested against the exact state your PR will merge into.
With this optimization, Trunk Merge Queue will recognize this situation and merge your PR directly without the unnecessary wait.
Set higher test concurrency for failure isolation without slowing down your main merge queue
When a batch of PRs fails and needs to be split apart to identify the culprit, you want those bisection tests to run as fast as possible so developers get quick feedback about what broke.
Previously, bisection tests shared the same concurrency limit as your main queue, meaning the isolation process could slow down other PRs waiting to merge. With independent concurrency settings, you can configure bisection to run at higher concurrency (spinning up more test runners to isolate failures ASAP) while keeping your main queue at its optimal setting.
This means faster root cause identification when batches fail, no impact on your main queue's throughput during failure investigation, and the flexibility to optimize each workflow independently. You can be aggressive about isolating problems without sacrificing the steady flow of successful PRs through your queue.
Intelligently reuse test results when isolating failures in batched PRs to save CI resources
When you use batching mode, the merge queue tests multiple PRs together for efficiency. If a batch fails, the queue needs to figure out which specific PR caused the problem by splitting the batch apart and retesting smaller groups.
With this optimization, the merge queue will recognize when it's about to run a test that it has already run during the isolation process. If we already know a test will fail based on earlier results, we skip rerunning it and reuse that information.
This means faster failure isolation when batches break, significant CI cost savings during the bisection process (especially important for large batches or expensive test suites), and quicker feedback about which PR needs fixing.
Auto-quarantining test cases have been updated to target only 'flaky' tests specifically. Previously, both 'flaky' and 'broken' tests were subject to automatic quarantine.
This ensures that only tests exhibiting inconsistent behavior (flakiness) are automatically quarantined, while genuinely broken tests require manual intervention or different handling.
Verify tests are broken using the test details page, and look for "Marked as Broken (Not Quarantining)" in the test history.
Resolved an issue where test failures were not being reported or displayed when using the --disable-quarantining flag.
What was happening: When --disable-quarantining was specified, failing tests were not being compared against quarantine state, preventing failure reporting and causing the CLI to skip displaying test failure information
Root cause: The quarantining check was being applied too broadly, affecting both quarantine state fetching AND test failure context building
Impact: Users saw no failure output and couldn't identify which tests were failing when using this flag
Resolution: Limited the quarantine disabling logic to only apply when fetching quarantine state, not when building test context
We've redesigned the app with a visual-first approach that helps you spot critical issues at a glance instead of digging through data. Plus, get a sneak peek at our new CI Autopilot interface!
Flaky Test Dashboard
Simplified test metrics display for faster comprehension
Redesigned history graph with linear timeline view (replacing stacked daily format)
Added "Most Unstable Tests" section to prioritize critical fixes
Enhanced visual-first design - optimized for scanning rather than reading
New manual override button for test status control
Improved test history with streamlined linear timeline
Merge Queue
Updated merge queue timeline for clearer workflow visibility
Enhanced merge log visuals with improved scanability and visual hierarchy
🚀 Sneak Peek: CI Autopilot
New dedicated interface for CI Autopilot (Beta preview)
A new endpoint is available from the trunk api at /flaky-tests/list-unhealthy-tests for your CI/CD integrations. Open tickets based on PRs impacted or other theshholds for example.
CLI support for XCode 26 and for PR URL overrides.
New linter: ls-lint. Thank you @nenadfilipovic for the contribution!
✨ Improvements
Add new file types, jpg, gip, pcap, tif, webp
Update known_good_version for shellcheck, flake8, prettier, black, tflint. Thank you @yu-iskw for the contribution!
Ignore list for a linter will no longer error if a specifically ignored file in the list is not found. This better matches behavior of glob pattern ignores.
We’ve added additional details about commits that trigger test status changes to test timelines in the Flaky Tests dashboard.
A test will be identified as flaky if it produces inconsistent results on the same git commit. This is often seen when test failures are automatically retried in CI. This flaky behavior can be detected on stable branches (for example, main), PR branches, or merge branches.
Previously, Flaky Tests did not specify what type of commit led to a status change in the flaky test dashboard. The same “Inconsistent results on the same commit” message would be included in the timeline on the test details page.
Now, the timeline will say where inconsistent test results are seen, whether it is a stable, PR, or merge commit:
When there is a status change due to a stable branch commit, the name of the branch will be included in the message.
This helps to easily identify the source of flakiness when tests are rerun on the same commit.
You can now manually set a test’s status to Flaky, Healthy, or Broken in the Flaky Tests dashboard.
This means you can take advantage of Flaky Tests quarantining to unblock CI when you already know that a test has a high chance of failing, like in the case of a service outage affecting end-to-end tests.
This is not a permanent override. Flaky Tests will continue to classify this test using this new status.
For example, if a test status is manually set to Healthy but becomes flaky after a series of CI runs, Flaky Tests will mark the test as Flaky.
To update a test’s status:
Click the Edit button next to the test status in the Flaky Tests dashboard:
Enter a comment, and click Save Status.
The status change and comment will appear in the timeline on the test detail page.
Manual test status overrides will not be enabled by default. Reach out to us on our community Slack to enable it for your organization.
The names of a test’s suite and class are now visible on the test details page of the flaky test dashboard, along with a file search link for repos using either GitHub or Bitbucket as source control providers.
This additional information helps you navigate to the correct test when investigating flakiness or failures, and is particularly helpful in large projects and monorepos.
The suite and class will only be displayed if your test framework reporter includes that information in the JUnit XML test report uploaded to Trunk.
We will also attempt to add a file search link for projects using GitHub or Bitbucket for source control. It is not always possible to provide a link to the file, depending on how project files are compiled and whether or not those files are available in source control.
We’re happy to announce that a new test_case.quarantining_setting_changed webhook is now available for all Flaky Tests users.
This webhook is fired when a test’s quarantine setting is manually changed between ALWAYS_QUARANTINE, NEVER_QUARANTINE, or UNSPECIFIED, where UNSPECIFIED means that the repo’s quarantine settings will be applied to the test case.
The webhook payload contains useful details like the new and previous settings, a user-inputted reason for the change, who made the change, and all the info you need for the affected test case:
1{
2"quarantine_setting_changed":{
3"actor":{
4"email":"riley@trunk.io",
5"full_name":"Riley Draward"
6},
7"previous_quarantining_setting":"UNSPECIFIED",
8"reason":"Test is important, should not be quarantined!",
This allows you to build automations and custom workflows when a test’s quarantine setting is changed, such as automatically creating Linear or Jira tickets to fix flaky or broken tests marked as ALWAYS_QUARANTINED, or sending a message to the team in Slack so everyone is kept up to date on status changes.
To subscribe to the new webhook:
Go to Settings in the Trunk app.
Click on Webhooks under Organization.
Click Add Endpoint and connect to an existing endpoint, Slack, MS Teams, Linear, or Jira.
Python runtime environment now passes thru required environment variables for PIP and Request component to work correctly with proxies and custom certificates
Updated dependencies in local package.json and node runtime bumped to 22 LTS
🔧 Fixes
Fixed up some testing environment to better support some linter specifications
