Sandbox tests

Anyone can read a test run. Turning sandbox tests on for a repository is an admin task.

#What a run gives you

FAIL src/lib/review/cache.test.ts
  reuses a cached review when the head is unchanged
    Expected 1 call, received 2

You see every step inline took, how long each took, and the terminal output it produced. A failing test shows the same output you would see running it yourself.

A run ends in one of three states: passed, failed, or running while it is still going. The run opens from the review, and every step is expandable.

#Where your code runs

Each run happens in an ephemeral, isolated microVM, cloned fresh for that pull request and torn down afterwards. The same applies to code-graph builds, fix verification and pentest validation.

#Test results in the merge gate

A run can feed the inline / review check alongside the findings. Auto follows whatever you set the merge gate to, and the other three settings decide on their own: Off, Report, or Block.

A failing test fails the gate. A run still going keeps the check in progress, so nobody is blocked by a slow suite. See The merge gate.

#Share a run

Every run has a link that works without a workspace account, so you can send a failure to whoever needs to look at it. Someone opening a run still in progress sees Running tests in a sandbox and the steps as they complete.

#Turn it on

Switch Sandbox test runs on for a repository in Repository settings, or set the workspace default in Review config. Commenting @inline test on a pull request runs the suite once, on demand.