Changelog

Programmatically create, configure, and manage merge queues via REST API

You can now fully manage your merge queues through the Trunk API without touching the web UI.

• Create new queues with /createQueue, specifying your target branch, mode (single or parallel), and concurrency settings. Update queue configuration on the fly with /updateQueue—adjust concurrency, enable batching, set testing timeouts, pause or drain the queue, and more.

• Query queue status with /getQueue and clean up with /deleteQueue when a queue is no longer needed.

This opens up powerful automation possibilities: spin up queues for new release branches as part of your release process, dynamically adjust concurrency based on CI capacity, integrate queue management into your infrastructure-as-code workflows, or build custom dashboards using queue data. Teams managing multiple repositories or complex branching strategies can now script their entire merge queue infrastructure instead of clicking through settings one by one.

Read the Docs to learn more

When infrastructure issues like database outages, network problems, or CI runner failures cause a large number of tests to fail simultaneously, retrying those tests can trigger mass false flaky detections. Infrastructure Failure Protection identifies these scenarios and excludes them from flakiness detection.

By enabling this setting, you can set a threshold for filtering runs based on the percentage of failed tests; if failures exceed 80%, those tests won't be processed for flaky test detection and you'll see a new status in the Uploads tab indicating 'Upload Skipped Due to Infrastructure Error'.

Read the Docs to learn more

Get direct messages in Slack about your PRs in the merge queue, keeping you informed without adding noise to team channels and allowing you to address failures immediately.

Receive personalized Slack DMs when your PRs are queued, start testing, pass tests, get merged, or encounter issues. By linking your GitHub account to your Trunk account and configuring your notification preferences, you'll stay up-to-date on the progress of your code through the merge queue without needing to check the web UI or monitor shared channels.

This means you can focus on your work while staying informed about your own PRs, get immediate alerts when your PR fails so you can address issues right away, and reduce noise in team channels by keeping personal updates private. Whether you're waiting for a critical hotfix to merge or just want peace of mind about your code's progress, personal notifications ensure you never miss an important update about your pull requests.

To get started, navigate to User Settings > Notifications, connect your GitHub and Slack accounts, and choose which events should trigger notifications. You can customize exactly which updates you want to receive, from every stage of the merge process to just the critical events like failures and successful merges.

Read the Docs to learn more

Choose how your PRs get merged: squash, merge commit, or rebase.

You can now select your preferred merge method for PRs going through the merge queue. Previously, Trunk Merge only supported squash merging, which combines all commits into a single commit. Now you can choose between:

• Squash (default) - Combines all commits into a single commit

• Merge commit - Preserves all individual commits and creates a merge commit

• Rebase - Replays commits on top of main for a linear history

This flexibility means you can match your team's existing Git workflow preferences, maintain your desired commit history style, and satisfy different requirements across projects. Whether you want a clean linear history with squash, full commit preservation with merge commits, or a streamlined history with rebase, your merge queue now adapts to your team's practices instead of forcing you to change them.

Read the Docs to learn more

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.

Read the Docs to learn more

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.

Read the Docs to learn more

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.

Read the Docs to learn more

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.

Read the Docs to learn more

We’ve added three new endpoints to make it easier to investigate flaky tests, automate triage, and integrate test health into your workflows.

📝 /flaky-tests/get-test-details

You can now retrieve details for a single test by ID, without having to paginate through entire lists of unhealthy tests.

What’s new?

• New request-body filter: test_id

• Response returns only the matching test

• Enables fast, targeted detail lookups for downstream automations

Read the Docs

🫙 /flaky-tests/list-quarantined-tests

A new way to list quarantined tests with the timestamp of when each test was quarantined.

What’s new?

• Response now includes the timestamp of when the quarantine override was created

• If no override audit log exists, the timestamp defaults to the test’s status-change time

• Ideal for automated “this test has been quarantined too long” workflows

Read the Docs

⚠️ /flaky-tests/list-failing-tests

A new endpoint to help teams select which tests should run during weekly flaky-test burn-down jobs.

What’s new?

• Query for tests that have failed within the last week

• Helps keep flaky jobs focused, faster, and more cost-efficient

• Useful for scheduling targeted “high-value” retest runs

Read the Docs

✨ Improvements

• Improve dart configuration. Thanks @AndrewDongminYoo for the contribution!

• Update linters' known_good_version to latest validated

🔧 Fixes

• Support dotenv-linter@4.x

• Fix latest terragrunt support

🎁 New

• New formatter, nbstripout. Thanks @NellyWhads for the contribution!

✨ Improvements

• Add all supported config paths for cspell. Thanks @casaper for the contribution!

🔧 Fixes

• Fix hadolint download urls for >=2.13.1. Thanks @gejustin for the contribution!

• Fix install for psscriptanalyzer

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)

• Stay tuned for more details coming soon!

• 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.

• Onboarding UX improvements

• Stacked PR User experience improvements to generate less noise in your repo/feeds

• Support for commands in GitHub comments (give /trunk fix)

• Added triggers on CI failures, rather than only triggering on bulk uploads

• MCP support - get root causes and recommendations

🎉 CI Autopilot Private Beta is Live

Core features in this release:

• Automatic root cause analysis of failing tests and CI jobs

• AI-powered fix generation with stacked PR creation

• Integration with GitHub Actions and popular test frameworks

🎁 New

• 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.

• Performance improvements in launch time

• Various bug fixes

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.