Quick Reference
What each action does
A rule carries 1 or 2 actions. Quarantine and tag can be combined. Skip is exclusive, because a skipped test never produces a result to quarantine or label.
Quarantine changes one thing and one thing only: the CI exit code. TestDino still records the failure as a failure. A quarantined run does not turn green in the dashboard, and status filters on the test runs list stay raw. The run details header shows an amber count of quarantined tests instead.
Create a rule
1
Open Workflows
Go to Workflows in the project sidebar and select Create Workflow. On an empty project the page shows No rules yet with a Create your first rule button.
2
Name the rule
Under Basics, give the rule a name of up to 200 characters. A reason note is optional and holds up to 1000 characters. It appears in the audit history, so future readers know why the test was silenced.
3
Set an expiry
Pick one of
+1 day, +3 days, +1 week, +30 days, or choose a date. Expiry is required and cannot be more than 365 days out. When the date passes, the test counts normally again.4
Choose which tests match
Under Which tests, add conditions. Each condition is a field, an operator, and one or more values. See Workflow rule conditions for the full field and operator reference.
5
Choose what happens
Under What happens, pick Skip, Quarantine, or Tag only. Tag mode requires at least 1 tag; quarantine can optionally add tags too.
6
Save
The form states
Changes take effect on your next test run. Nothing changes in the run you are currently looking at.Rule status
Status is derived from the rule, not set by hand. A manual disable outranks expiry.
Filter the Workflows list by any of these. Disabling is reversible and keeps the rule’s history, so it is the safer choice when you want a rule back later.
See what a rule affected
Silencing a test does not hide it. 2 views answer what a rule has done.
Individual test results carry a chip naming the rule that touched them, on both the test run details page and the test case view. A test run that had tests skipped by a rule lists them on the run details page.
Audit history
Every rule keeps an append-only event log:created, updated, disabled, enabled, and deleted. Each event records who did it and when.
Deleting a rule removes the rule, not its history. The deleted event embeds a final snapshot of what the rule said, and action traces already recorded on past test results survive as well. “Who silenced this test, and what did the rule match?” stays answerable after the rule is gone.
Permissions
Creating, editing, enabling, disabling, and deleting a rule requires an organization owner or admin role. Members can read rules and their affected tests. This uses the existing organization role model, so there is no separate permission to grant.Requirements
Rules are applied by the CLI at run time, so the reporter has to be recent enough to fetch and apply them.Related
Workflow rule conditions
Every field and operator you can match on, and the limits that apply.
Workflow rules API
Create and manage rules over the public REST API.