Rules for pull requests and deployments

A rule tells Rehearsal when to run tests by itself. It answers three questions: when to run, which tests, and which address to test. The rule then reports each run as a check on the commit.

You need a connected repository and Manage integrations, which the admin and owner roles include.

Add a rule #Link to Add a rule

1. 1

   Step 1: Open the rules

   Open Deployments in the sidebar and press Rules. Then press Add a rule.

2. 2

   Step 2: Choose when tests run

   Option	You write	It covers
   When a pull request is opened or updated	The target branch, such as main	Pull requests into that branch
   When a branch is updated	A branch, such as main	Pushes and merges to that branch
   When a branch matching a pattern is updated	A pattern, such as release/*	Every branch the pattern matches

   In a pattern, * stands for any characters, so release/* matches every branch that starts with release/. Only a pattern may use *.

3. 3

   Step 3: Choose the tests

   Pick a suite, or All approved tests. If the project has more than one address, choose one under Address to test. All approved tests then means the approved tests of that address's app.

4. 4

   Step 4: Choose the address

   Option	Use it with	What Rehearsal tests
   The pull request's Vercel preview	Pull request rules	The preview Vercel builds for the pull request's newest commit
   Vercel's deployment of the branch	Branch and pattern rules	The deployment Vercel builds for the branch
   The same address every time	Branch and pattern rules	The address you write under App address

5. 5

   Step 5: Save the rule

   Press Save rule. The rule applies from then on.

As you answer, a sentence at the top of the page fills in. For example: "When a pull request into main opens or changes, run Checkout on its Vercel preview and report the result in GitHub."

Below the sentence is the name of the rule's check in GitHub. A pull request rule reports as Rehearsal. A branch rule adds its branch, such as Rehearsal · main.

When tests start #Link to When tests start

Preview deployments follows a pull request from start to finish.

A fixed address #Link to A fixed address

With The same address every time, Rehearsal tests the app as it stands when the push arrives. It cannot tell which commit the app serves, so the check says so: "Its deployed commit was not verified."

Use it for an address that always serves the branch, such as a Staging environment. To test a known commit, use a Vercel rule.

Which tests a run checks #Link to Which tests a run checks

• A suite runs its tests. All approved tests runs every approved test of the app.
• The versions of those tests are fixed when the run starts. A test that changes later does not change that run.
• A suite can reach another app. If that app has more than one address, the check stops and names the app, because the rule does not say where to test it.
• When the workspace has no runs left, the check says so and no tests run.

One rule per situation #Link to One rule per situation

Two rules cannot describe the same thing: the same kind of rule, on the same branch, at the same address. Rehearsal refuses the second one with A rule already covers that branch at this address.

Pause, change or remove a rule #Link to Pause, change or remove a rule

Each rule on the Rules page shows its sentence and its last runs.

• Pause stops the rule. It keeps its history and starts nothing until you press Resume.
• Edit opens the same three questions. A new branch gives the check a new name, so make that name required in GitHub again.
• Remove stops Rehearsal checking the branch. Runs that already finished keep their results.

Next steps #Link to Next steps

• Require the check so a pull request cannot merge until its tests pass.
• Read what each check says.