Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion flaky-tests/detection/pass-on-retry-monitor.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ description: "Detect tests that fail then pass on retry within the same commit"
---
The pass-on-retry monitor detects the most common flakiness pattern: a test fails, is retried, and passes on the same commit. This indicates the failure wasn't caused by a code change and that the test is unreliable.

This monitor is branch-agnostic. It evaluates all test runs regardless of which branch they ran on.
By default, this monitor evaluates test runs on all branches. You can scope it to specific branches to focus detection where pass-on-retry behavior is actually meaningful.

## How It Works

Expand All @@ -29,11 +29,26 @@ Seven days later (assuming default settings), if `test_login` hasn't exhibited a
| ----------------- | ---------------------------------------------------------------------------------------------- | ------- |
| **Enabled** | Whether the monitor is active | On |
| **Recovery days** | Days without pass-on-retry behavior before a test is resolved as healthy. Range: 1 to 15 days. | 7 |
| **Branch scope** | Which branches the monitor evaluates. Accepts branch names and glob patterns. | All branches (`*`) |

### What Recovery Days Controls

A shorter recovery period (e.g., 1 to 3 days) returns tests to healthy quickly, which is useful if you fix flaky tests promptly and want fast feedback. A longer recovery period (e.g., 10 to 15 days) is more conservative. It keeps tests flagged longer to account for flaky behavior that only surfaces occasionally.

### Branch Scope

Use the **Branch scope** setting to restrict the monitor to a specific set of branches.

This is useful when PR branches generate too much noise. CI often retries tests on pull request branches automatically; if those retries aren't meaningful signals for your team, you can limit detection to stable branches like `main`.

Branch scope uses the same glob syntax as [threshold monitor branch patterns](/flaky-tests/detection/threshold-monitor#branch-pattern-syntax) and accepts up to 10 patterns. Type a pattern and press **Enter** or comma to add it as a chip. For example:

- `main`: only stable branch runs
- `main` and `release/*`: stable plus release branches
- `*` (default): all branches

Changes to branch scope take effect for newly detected events. Previously detected flaky tests are not re-evaluated.

## When Detection Happens

Pass-on-retry detection runs continuously as new test results arrive. A failure and its corresponding retry don't need to arrive at exactly the same time.
Expand Down
58 changes: 24 additions & 34 deletions flaky-tests/ticketing-integrations/jira-integration.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -86,50 +86,40 @@ If you are connected to Jira, you can click the **Create Jira Ticket** button at

If you already have a ticket in Jira that you want to link to a test in the dashboard, you can use the [Link Ticket to Test Case API](/flaky-tests#post-flaky-tests-link-ticket-to-test-case).

### Required Custom Fields
### Custom Fields

Some Jira projects require additional fields beyond the standard fields (like summary, description, and issue type) to be specified when creating tickets. Common required custom fields include:
Some Jira projects require additional fields beyond the standard fields (summary, description, and issue type) when creating tickets. Trunk supports configuring default values for any Jira field on a per-issue-type basis. Users can also override those defaults when creating a ticket.

* **Components** - Categories or modules within your project
* **Affects Version** - Which version of your product is impacted
* **Fix Version** - Target version for the fix
* **Epic Link** - Parent epic for the ticket
* **Sprint** - Sprint assignment
* **Story Points** - Estimation field
* Custom fields specific to your organization
#### Configuring custom fields

#### Enterprise Feature
In the Jira integration settings (**Settings** -> **Repositories** -> **Ticketing Integration**), select an issue type. Trunk fetches all available fields for that issue type from the Jira API and displays inputs for each supported field.

<Warning>
**Support for required custom fields is an Enterprise feature.**
</Warning>
For each field, you can:

If your Jira project requires custom fields that aren't supported in the standard Trunk Flaky Tests integration, you'll see an error message when attempting to create a ticket:
* Set a default value that pre-fills the field when a ticket is created
* Check **Require user to fill at creation** to leave the field blank in settings and prompt the user to fill it in the create ticket modal instead

```
The Jira project [PROJECT_KEY] requires a field "[field_name]".
Contact sales@trunk.io to upgrade your account for custom field support.
```
Trunk automatically detects required fields (as marked by your Jira project) and shows a validation error if no default is set and the field is not marked for user input.

To enable support for your required custom fields, contact our sales team at sales@trunk.io to discuss Enterprise plan options.
Fields are rendered using an appropriate input type based on the Jira field schema:

#### Alternative: Remove Field Requirements
| Jira schema | Input type |
| ---------------------------------------- | ----------------------------------------- |
| `string` | Text input |
| `number` | Number input |
| `option` | Searchable dropdown |
| `user` | User picker dropdown |
| `array` of `string` | Chip input (comma or Enter to add values) |
| `textarea` / `string` with textarea hint | Textarea |

If you don't need Enterprise features, you can modify your Jira project settings to make custom fields optional instead of required. This allows Trunk Flaky Tests to create tickets without needing to specify those fields.
<Info>
The `reporter` field is treated as optional even when Jira marks it as required. Jira automatically assigns the API token owner as reporter if the field is not specified.
</Info>

**To make a field optional in Jira:**
The following fields are always excluded from the custom field configuration because they are managed elsewhere in the ticket creation flow:

1. Navigate to **Project Settings** in your Jira project
2. Select **Issue Types** from the sidebar
3. Choose the issue type you're using for flaky test tickets (e.g., Task, Bug)
4. Click **Fields** to see all fields for that issue type
5. Locate the required custom field (e.g., "Components")
6. Click the field to open its configuration
7. Uncheck **Required** or change the field requirement setting
8. Save your changes
`summary`, `description`, `project`, `issuetype`, `attachment`, `issuelinks`, `parent`

After making the field optional, you should be able to create tickets through Trunk Flaky Tests without encountering the error.
#### Overriding defaults at ticket creation

<Info>
**Note:** You may need Jira Administrator permissions to modify project settings. If you don't have access, contact your Jira administrator to make these changes.
</Info>
When creating a ticket from the Flaky Tests dashboard, the create ticket modal shows inputs for any field that has a configured default or is marked for user input. Users can edit pre-filled defaults before submitting.