Skip to main content
TestDino Actions changes how a test behaves without a code change: skip it, quarantine it, or add a tag to its result. You create a rule in the dashboard, and the TestDino CLI applies it inside the Playwright process on your next test run. Find it under Actions in the project sidebar.

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 Actions

Go to Actions in the project sidebar and select Create Actions. 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 Action 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.
You can also start from a failing test. Open the test case in a test run and create a rule from it, and the form arrives pre-filled with that test’s details.

Rule status

Status is derived from the rule, not set by hand. A manual disable outranks expiry. Filter the Actions 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. Two 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.
If the CLI cannot reach TestDino when a test run starts, it proceeds with no rules rather than blocking your run. A rules fetch never fails or delays CI.

Action rule conditions

Every field and operator you can match on, and the limits that apply.

Action rules API

Create and manage rules over the public REST API.