Changelog

Trunk CI Analytics and Code Quality web issue browser are being shut down today. This is a strategic change as we reinvent and consolidate our tools for the future.

What’s changing?

• CI Analytics has been shut down as of today.

• Code Quality’s web issue browser has been shut down as of today.

• Code Quality workflows like Check Nightly and Check on PRs have been marked as deprecated and will be shut down on July 27th, 2025.

The core value of Code Quality comes from the CLI, IDE, and CI integrations, and these critical components will continue to work as they always have.

Code Quality migration

Checking for issues nightly and on pull requests has been marked as deprecated. You can check if you’re using these features in the Code Quality section of your repo settings. You can still run Code Quality in CI if you migrate your workflow following this guide.

Code Quality will no longer collect your linting issues, which means the --upload flag will no longer work. You will also stop receiving Slack notifications about new issues discovered by linters.

1# --upload will no longer work
2trunk check --upload --series=main

What's next?

AI has changed the way we work. It allows us to go beyond traditional dashboards to surface root causes of test and CI instability and develop AI-driven tools to address these problems. We have shut down these parts of Trunk to unify them as a single AI-powered DevEx platform.

We can’t wait to show you what’s next. You can follow our progress by signing up for our in-app waitlist. If you have questions or concerns, please reach out via email (support@trunk.io) or Slack.

We now have a built-in Linear integration that creates tickets with relevant test and failure information from your flaky tests.

Detecting and quarantining flaky tests aren’t the only steps required to eliminate them from a repo. A follow-up process must also be established to collect, triage, and fix flaky tests.

Ticketing system integrations help with that follow-up. Trunk generates tickets automatically from detected flaky tests, enabling you to triage and address flakes. Flakes on important tests should be dealt with immediately, and other flakes can be added to a backlog or the tests can be marked for future removal.

To set up the Linear integration:

• Go to your repo settings: Settings > repo > Ticketing Integration.

• Select Linear as your system and enter a Linear API key.

• Select a team and connect to Linear.

You can also select a default project and assignee for newly created tickets. This enables you to designate a person on a team to triage, prioritize, update, and assign tickets for flaky tests when they are created.

Once the integration is set up, you can create a new ticket:

• In the options menu on the test cases overview dashboard.

• With the Create ticket button on the test details dashboard.

You will see a preview of the ticket title and description, and can click Create Linear Ticket to create the new ticket.

When a ticket is created, any changes to that ticket, such as status or person assigned, are also visible in the timeline on the test case details page in Flaky Tests.

Read the docs for more information on setting up the Linear integration.

Today, we’re introducing a new Link Ticket to Test Case API that allows you to link your existing Linear or Jira tickets to tests in the Flaky Tests dashboard.

Trunk has built-in ticketing integrations with Jira and Linear, allowing you to create detailed bug tickets for flaky tests with a single click. If you’re already tracking flaky test issues with existing tickets, you can now link those Jira or Linear tickets directly to your flaky tests in Trunk, keeping all relevant context in one place.

Calling the API requires the ID of your test case in Flaky Tests, which can be found on incoming webhook payloads or the URL of the test case details page, and the ID of the ticket in your ticketing system:

1curl -L \​
2  --request POST \​
3  --url 'https://api.trunk.io/v1/flaky-tests/link-ticket-to-test-case' \​
4  --header 'x-api-token: YOUR_API_KEY' \​
5  --header 'Content-Type: application/json' \​
6  --data '{
7    "test_case_id": "01234567-0123-0123-0123-0123456789ab",
8    "external_ticket_id": "KAN-123"

Once a ticket is linked to a test, ticketing information will be available in Flaky Tests webhooks. This makes it possible to build custom integrations and automations with the context of any linked ticket information. And when ticket information is not included in the payload, you know one has not been created for the flake.

You can only use the Link Ticket to Test Case API if you have already set up the Linear or Jira integration.

Read the reference docs for more information on the Link Ticket to Test Case API.

Starting today, the --variant option should be used to upload test results when the same tests are run on different environments, also known as matrix builds.

If you use a matrix strategy to run the same CI tests on different architectures or environments, test flakiness could be unique to an environment. Examples include testing a mobile app on iOS and Android, running tests for your CLI tool on macOS and Linux, or performing the same e2e tests on different browsers. Tests run on separate environments must be treated as unique to guarantee accurate flake detection.

Using variants, Flaky Tests will now treat the same test run on different environments as unique. This means flakes can be detected and quarantined on a per-environment basis.

To specify a variant during upload, use the --variant option:

1./trunk flakytests upload --junit-paths "test_output.xml" \
2--org-url-slug <TRUNK_ORG_SLUG> \
3--token $TRUNK_API_TOKEN \
4--variant linux_x86_64

Variant names are visible in brackets on your Flaky Tests dashboard:

See the reference docs for more information on uploading test reports with variants.

🎁 New

• New linter: golangci-lint2. Users who wish to upgrade should replace golangci-lint with golangci-lint2

✨ Improvements

• Add in-repo docs for converting some native linter ignores to trunk-ignore

• Update kube-linter to 0.7.2. Thanks @janisz for the contribution!

• Update ruby build and latest stable ruby release to 3.4.2

🔧 Fixes

• Fix Dockerfile file pattern regex to match spec

The test details page in the Flaky Tests dashboard is getting a major UX overhaul.

User interviews and feedback from beta users helped us remove metrics that were not useful and update visualizations to better show a test’s health over time. The tabbed views are also gone, which means you can get all the information about a test’s health in a single, unified dashboard, including: 

• A test’s current status.

• When a test was marked as flaky and quarantined.

• Test flake and failure rates on mainline and PR branches.

• Overall test health history.

• Grouped unique test failure reasons.

These new charts break down how often a test is successful, failing, or quarantined for CI jobs for your mainline branch and PRs and show test health changes over time.

A more eventful test history timeline

The test history timeline has been moved to the main page, and updates, including when a test was marked as flaky, quarantined, or fixed, are always visible. Teams using the Jira integration to track test flakes will also see any updates to a flaky test’s ticket reflected in the timeline.

You can still override the repo's default quarantine setting and always quarantine or never quarantine a test, but now you can leave a comment for other devs that shows up in the timeline.

For example, you might want to let your team know that the “Test is important - flakes must be fixed!” when you override the repo default to never quarantine a test:

The table shows all the unique reasons the test fails in CI.  Trunk uses AI to auto-group unique failures so multiple runs will be grouped under a single failure reason. Individual runs, including stack traces, branch, commit, and job information, are available when a row in the table is expanded. This means all the information you need to debug and fix flaky or broken tests is available in a single place.

Have feedback for us? Reach out on our community Slack.

A new Quarantined Tests API is now available to all Flaky Tests users. This API fetches a list of currently quarantined tests for a given repo, allowing organizations to implement custom workflows to review and fix quarantined tests.

1// https://api.trunk.io/v1/flaky-tests/list-quarantined-tests
2// a sample response with a single quarantined flaky test
3{
4  "quarantined_tests": [
5    {
6      "name": "sums some nums > subtracts 1 from 2 to equal 1",
7      "parent": "app/utils/subtract.test.ts",
8      "file": null,
9      "classname": "app/utils/subtract.test.ts",
10      "status": "FLAKY",
11      "codeowners": [],
12      "quarantine_setting": "AUTO_QUARANTINE",
13      "status_last_updated_at": "2025-02-13T15:52:03.000Z",
14      "test_case_id": "48cd26cb-6333-528a-919f-ed597ee11715"
15     }
16   ],
17   "page": {
18     "total_rows": 1,
19     "total_pages": 1,
20     "next_page_token": "",
21     "prev_page_token": "nUj35JF5aNJFjUkIakxff89f1b...",
22     "last_page_token": "bVUNwekgkHadgZfSgwuac75640...",
23     "page_index": 0
24   }
25}

Dev teams are using the Quarantined Tests API to do things such as:

• Automatically skip quarantined tests when testing locally

• Check for any tests that should be manually un-quarantined

• Determine what teams, projects, or modules have the most quarantined tests

• Assign engineers to fix certain quarantined tests, based on recent code changes

• Send Slack or email notifications to let teams know when the number of quarantined tests reaches a threshold

See the API reference for more information on required headers and payload.

Trunk now supports single sign-on (SSO) for enterprise plan users. SSO allows your team to access Trunk with their work email account through your organization's identity and access management solutions, making it easier to manage your Trunk organization.

SSO is only available for enterprise plan users. If you're interested in configuring SSO for your team, contact us by email or Slack. We will reach out to help you configure SSO for your organization.

We have an exciting update for teams using the Flaky Test Jira integration to create and track their tickets.

Previously, the Jira integration only tracked ticket creation in each test's timeline. In this update, new events are added to the timeline for ticket assignments and status changes.

As your team continues to integrate Trunk into your workflow, Jira integration events combined with detection events in the timeline help tell a more complete story about the status of a flaky test. You can more easily understand if a flaky test is being tackled by an engineer and if their fix was effective during reviews.

Note: There can be a delay of up to 15 minutes between changes being made in Jira and the events being reflected in the timeline.

See the new timeline events in Trunk or reach out to us for discussions on Slack.

If your stable branch is not main, you can now set a custom stable branch for your repositories to improve flaky test detection.

Previously, Flaky Tests assumed that main was a repository's stable branch. This would lead to subpar flaky test detection if a different branch, master or develop for example, is defined as the default stable branch for your workflows.

Now you can override these stable branch defaults to better match your organization's custom CI workflows.

Learn how to customize your stable branch in the Trunk docs.

We're excited to introduce a new way to help your team stay on top of your repository's test health through weekly email reports.

With automatic detection and quarantining, Trunk can do a great job of mitigating the impact of test flakiness on your team's velocity. But we don't want you to forget about your flaky tests. Even if they're no longer causing friction, they should still be fixed eventually.

To help you stay on top of your repo's test health, we created a weekly digest for your flaky tests. Here's what you can expect to find in each report.

Key Metrics

At the top of each report, you'll see an overview of important metrics on flaky tests and their impact on your organization. You'll see the number of broken and flaky tests, how many PRs they block, and an estimate of engineering hours lost due to these flaky tests.

We also include the changes week to week. We believe it's important to keep track of week-to-week changes to understand if the flaky tests problem is controlled or if it's spreading. This helps you decide whether more resources should be devoted to fixing and controlling flaky tests. It can also alert against larger issues where a bug in code or infrastructure can cause a spike in test flakiness.

Per-Repo Breakdown

If your org is tracking flaky tests across many repos, the weekly report will break down the key metrics for each repo. This helps you see which repos are doing well and which might need extra love.

Frequently Failing Tests

Each report has a dedicated section for frequently failing tests. This alerts against high-impact broken and flaky tests. You can use this list to catch newly introduced high-impact flaky tests or get an overview of the flaky tests you should be investigating next with your team.

Important Action Items

Toolrot can be a real issue with the sheer scale of infrastructure required for modern CI. The weekly email reports will remind you if your CI is misconfigured or if there's a new version of the analytics-uploader tool you should upgrade to. All of these help ensure your detection remains accurate and effective.

Who Gets These Reports?

All org admins will get the emails by default as long as you've uploaded test results to us in the past week. The emails are delivered each Monday, and we go over the stats over the last week. You should see these emails in your mailbox starting next week.

If you've got any questions about these email reports or would like to suggest some new additions, please feel free to reach out to us on Slack.

We're excited to introduce webhook integrations for Slack, Microsoft Teams, GitHub Issues, and Linear. Webhook integrations make it easier to start automating notifications and ticket creation by providing tighter integrations and example transformations.

You can use the provided transformation to set up working notification messages and tickets immediately and customize the transformation for each webhook as you go. This means they're quicker to boot without sacrificing customizability.

Learn to set up webhooks and see examples in the Trunk docs

🎁 New

• New security linter: snyk. Thanks @fsargent for the contribution!

• New action: terraform-docs. Thanks @Gowiem for the contribution!

✨ Improvements

• Add support for biome.jsonc configuration file. Thanks @andreilgeorgescu for the contribution!

• Add other supported languages to Biome configuration. Thanks @andreilgeorgescu for the contribution!

• Use mjs file for default svgo configuration

• Add support for Astro files. Thanks @andreilgeorgescu for the contribution!

• Change biome to apply safe autofixes. Thanks @andreilgeorgescu for the contribution!

🔧 Fixes

• Fix Dockerfile file type specification. Thanks @NellyWhads for the contribution!

• Remove tf.json filetype from terraform

We're excited to share our new webhook integrations for Trunk Merge. You can now send notifications about events in the merge queue to your Microsoft Teams and Slack channels.

These webhooks allow you to receive notifications when a PR enters the merge queue, begins testing, and succeeds or fails in the queue. These webhook come with a template transformation that works out of the box and can be customized using a JavaScript-based transformation code block.

You can create an integration under Organization > Webhooks by clicking Add Endpoint. Under Webhook, you can select the type of integration for your messaging service. Instructions are provided in each of the provided integrations.

Login to Trunk to add a webhook integration

The Trunk Web App now supports signing in with Microsoft. This makes it easier for teams who are primarily integrated with Microsoft's ecosystem (Outlook, Microsoft Teams) to get started with Trunk.

Login with your Microsoft account today

We’re thrilled to announce support for CODEOWNERS in our Flaky Tests product, which is available for both GitHub and GitLab repositories. With this integration, we now process your CODEOWNERS file to identify and annotate ownership for tests automatically. This unlocks powerful capabilities for test ownership and management, including:

Test Details View: Instantly see who owns each test right from the test details page.

Webhook Integration: Retrieve ownership information in your webhooks for automated workflows.

1{
2
3   "status_change": { ... },
4
5   "test_case": {
6
7       "codeowners": ["@agraebe", "code", "owners", "@dev-team"],
8
9       "id": "fc7a6bdd-0ebe-55d5-aa31-ff0adb411d0e",
10
11... }
12
13}
14
15

Jira Integration: Automatically populate owner details in Jira tickets to streamline task assignments.

Why It Matters

CODEOWNERS is a key tool for maintaining code ownership within repositories. With this new integration, you can:

• Notify Owners: Automatically inform test owners in messaging applications like Slack or Teams when their tests exhibit flakiness.

• Streamline Workflows: Assign flakiness issues directly to owners using project management tools like Jira or Linear.

How to Get Started

It’s simple! Place your CODEOWNERS file in one of the standard locations supported by your Git provider and follow their conventions: GitHub and GitLab.

Here’s an example CODEOWNERS file:

1# In this example, @agraebe owns any file in the `/tests` directory  
2
3# at the root of your repository and its subdirectories.  
4
5/tests/ @agraebe 

Trunk Flaky Tests now supports uploading test results by parsing Bazel Build Event Protocol (BEP) files. Supporting BEP files gives Trunk more context when parsing Bazel test results for more accurate detection results. Parsing BEP files lets Trunk accurately track tests run by understanding which targets were actually built and which were cached and skipped. In the future, this will also allow Trunk to work better with Bazel's built-in retries.

Trunk expects a JSON serialization of the build event protocol which you can export by running the bazel test command with the options --nobuild_event_json_file_path_conversion and --build_event_json_file=build_events.json.

You can switch to uploading BEP files by running the upload command with the --bazel-bep-path build_events.json option.

1./trunk flakytests upload --bazel-bep-path build_events.json \
2--org-url-slug <TRUNK_ORG_SLUG> \
3--token $TRUNK_TOKEN

You can learn more about Bazel in the docs or chat with us on Slack.

We’re excited to announce improved flaky test detection for merge queue users. In a merge queue, a single flaky failure will force every enqueued PR behind it to be retested, affecting every engineer involved and wasting tons of CI resources. If you run a merge queue like Trunk Merge to test your changes before they're merged, tests run on the merge branches are an important signal about your tests' health. Flaky Tests can now detect flaky tests using signals on your PR branches, merge branches, and protected branches.

Tests are expected to behave differently on protected branches such as main or master compared to tests run on PR branches. Trunk adjusts for this inherent volatility of PR branches by applying a slightly different set of rules to them:

• Inconsistent test results on the same commit hash, where results are different on identical code is considered flaky

• Inconsistent test results on different commit hashes, but across a large number of PRs is considered flaky

Merge branches created by merge queues, on the other hand, are treated similarly to protected branches. We make the assumption that before PRs are submitted to a merge queue, tests have already been run once on the PR and are passing.

If you'd like to learn more about how Trunk detects flaky tests, see the Detection page in docs.

Trunk Flaky Test supports detection on merge branch for Trunk Merge, GitLab Merge Trains, Graphite Merge Queues, and GitHub merge queue. If you're using an unsupported merge queue and would like to apply detection on merge branches, contact us on Slack.

We’re excited to announce the addition of webhooks for flaky tests, designed to help you automate your workflows for better handling of flaky tests. The new test_case.status_changed event triggers whenever a test's status changes (healthy ↔ flaky ↔ broken). This makes it easier to track and respond to flaky tests as they show up. View the docs and example usage here.

With this update, you can automate actions to react to flaky tests in a way that suits you best. For instance, you can create tickets in project management tools (e.g. Jira, GitHub, Linear) and ensure they are automatically assigned to the right project and team. You can also automatically send notifications (e.g. in Slack, Discord, and Microsoft Teams) to the right engineers with the most relevant information, such as failure reasons and trace logs. This helps teams respond quickly, triage issues, and resolve flaky tests efficiently. Explore our webhook guide to get started.

✨ Improvements

• Upgrade ruby-build to 20241105. Thanks @amkisko for the contribution!

• Upgrade jdk to 23

• Upgrade rust to 1.82.0

• Upgrade php tooling to support 8.4

• Upgrade node to 18.20.5