Checks on pull requests

A code review reads the diff. Tada opens the build. When a deploy finishes, Tada checks the feature the pull request ships on that build. It posts the verdict on the pull request as a check named Tada, with a link to the report.

Before you start

• The app is connected through GitHub. See Add an app.
• Your host reports deploys to GitHub. Most hosts that deploy from GitHub do; the Deployments list on your repository shows whether yours does.
• The app has at least one feature. See Features and tests.

What happens on a deploy

1. A deploy to staging or to a pull request preview finishes.
2. Tada finds the feature the pull request ships, from the ticket id in its branch name or title.
3. Tada checks that feature in full at the address the deploy reports, as each person it needs, and films it.
4. Tada re-checks every other feature quietly beside it, as a guard. Each gets a verdict, with no film. A change that breaks one of them still fails the check.
5. Tada posts one verdict on that commit, and the pull request shows it.

A pull request counts as one check on your plan, however many features your app has. The quiet guard checks never count.

Tada checks deploys to environments whose names say they are for testing (staging, stage, qa, uat, test, sandbox) and to per-pull-request previews. It does not start checks by itself on production or development deploys. You can still check there yourself, or on a schedule. See App settings.

What the check says

	Conclusion	Title, for example
Passed	Success	All 3 tests passed.
Failed	Failure	Checkout stopped at step 3 of 5: click Pay.
Didn’t finish	Neutral	Tada couldn’t finish this check.

The check links to its report. For a failed check, the report shows the step that stopped and the film of what broke. A check that didn’t finish is never red, so a problem on Tada’s side never blocks your merge. See Verdicts.

Make a failed check stop the merge

Tada posts the check. Whether a failed check stops a merge is a GitHub setting on your branch.

1. On GitHub, open your repository’s Settings > Branches (or Rules > Rulesets).
2. Add or edit the rule for the branch you merge into, such as main.
3. Turn on Require status checks to pass before merging.
4. Add the check named Tada.

GitHub offers a check in that list only after it has appeared on the repository recently, so let Tada check one deploy first.

Tests kept in your repository

Tada keeps your features and tests itself, and never writes into your repository. If your team wants a test reviewed in the same diff as the code it tests, commit it as a file under .tada/flows/. Tada reads those files at the commit that deployed, so the check on that commit uses the new version, not last week’s. See Test file syntax.