Skip to main content
Trunk can manage the full lifecycle of a test’s ticket for you. When a test’s status changes, Trunk automatically:
  • Creates a ticket when a test becomes flaky or broken
  • Reopens the existing ticket (or creates a fresh one) when a fixed test regresses
  • Closes the ticket when the test returns to healthy
Automatic ticketing works with the built-in Linear, Jira, and Asana integrations and produces the same rich tickets as manual creation — full ticket content (failure history, impact, common failure reasons, code owners), your configured field defaults, and complete dashboard support: linked tickets appear on the test case details page, and every automated action is recorded in the test’s Events tab.

​
Enabling ticket automation

Connect an integration once for your organization, then choose it on each test collection that should file tickets.
  1. In the Trunk app, navigate to Settings → Organization → Ticketing and connect your Linear, Jira, or Asana integration. An organization can hold several — one Jira project for one team, another for a second.
  2. Open the collection’s Settings tab, then Ticketing, and select which of those integrations the collection files into by default.
  3. Configure the collection’s automation.
Automation is configured per collection, so two collections sharing one integration can still behave differently — auto-create for your end-to-end suite and nothing for your unit tests, for example. The collection’s integration is a default, not a restriction. It decides where automatic tickets are filed, and which integration the create-ticket modal opens on — but when you create a ticket by hand you can file it into any integration connected to your organization. The three toggles are independent — you can enable any combination: All settings default to off.
Automatic creation fills tickets from your configured field defaults with nobody in the loop. Every field your project requires must have a default set — fields marked Require user to fill at creation are prompted for in the manual create-ticket modal, which automatic creation can’t do.
Auto-close applies to whatever ticket is linked to the test — including tickets you created manually or linked yourself — not just tickets the automation created.

​
Close and reopen target statuses

When auto-close is enabled, you can pick which status closed tickets move to (for example Done vs. Won't Fix in Jira, a specific workflow state in Linear, or a project section in Asana). Similarly, reopened tickets can target a specific status. If you don’t pick one, Trunk uses a sensible provider default: the first “done”-category status for closing, and a “to do”-style status for reopening.

​
Reopen behavior

When a test becomes flaky or broken again after its linked ticket was closed, the Reopen behavior setting decides what happens: The reopen window is measured from the ticket’s close date in your ticketing system, so it behaves correctly whether Trunk or a person closed the ticket.

​
How the automation behaves

  • One ticket per test. Each test case has at most one linked ticket at a time. Previous tickets remain visible in the test’s event history.
  • Ticket content stays fresh. Auto-created tickets have their description refreshed as the test’s status evolves — for example when a flaky test escalates to broken — so the ticket always reflects current data. Title edits made by your team are preserved, and tickets you created or linked manually are never edited by Trunk (only closed or reopened per your settings).
  • Quiet updates. Status escalations update the ticket description in place rather than posting comments, so flip-flopping tests don’t generate notification noise. Comments are only posted on reopen and close, where the context matters.
  • Clearly attributed. Auto-created tickets are badged in the dashboard, and every automated action appears in the test’s Events tab attributed to Trunk automation — so it’s always clear whether Trunk or a teammate acted on a ticket.
  • Resilient to spikes. A mass status change (for example, a bad merge flipping many tests at once) is absorbed and drained at a pace that respects your ticketing provider’s rate limits.
For Jira, the configured close/reopen target status must be reachable in a single workflow transition from the ticket’s current status. If your Jira workflow requires intermediate steps, the automation records the issue in the test’s event history and skips the transition rather than guessing.

​
Repositories

Repository-level ticketing works the same way, with the integration configured on the repository rather than the organization: navigate to Settings → Repositories → [your repository] → Ticketing. Every setting described above behaves identically. The difference is flexibility: a repository has exactly one ticketing integration and cannot file into any other. Collections both choose from every integration connected to your organization and let you file a manual ticket into any of them, so migrating to collections is what buys you more than one destination.

​
Legacy webhook-based ticket autocreation

Before automatic ticketing, the recommended way to auto-create tickets was a webhook integration. Webhooks remain fully supported and are still the right tool for custom workflows and unsupported platforms, but the built-in automation is the better default for Linear, Jira, and Asana: