Tempo Visual Review

@tempo-ai/visual-review captures VRT-tracked Tempo storyboards in GitHub Actions and sends the results to Tempo for review.

The CLI is installed on demand by the generated .github/workflows/visual-review.yml (templates/visual-review.yml in this package):

npx --yes @tempo-ai/visual-review@latest capture --parallel 2

Commands: claim (announce a capture before dependency setup), install-browsers (the Chromium build matching the pinned playwright), capture, and report (commit status + sticky PR comment). capture reads the normal GitHub Actions event context, so the workflow never interpolates a pull request number, SHA, branch, merge-base, or repository.

Tempo's own repository runs the identical commands (.github/workflows/visual-review.yml in tempo-monorepo, pinned to this template by src/workflow.test.ts), so every release is exercised there before customers resolve it.

The current production ingest origin is the default. Set VISUAL_REVIEW_INGEST_URL only when using a Tempo preview deployment.

Every visual-review commit status is published by the Tempo Labs AI GitHub App, including no-visual-change declarations, bypasses, and workflow failures. The CLI authenticates these requests to Tempo with GitHub Actions OIDC; app credentials stay in Tempo. The workflow token is used for PR comments. If the app cannot publish, the job reports the failure instead of posting under a different identity that cannot satisfy an app-bound required check.

The backend checks the signed PR identity against GitHub's current head and reads skip declarations from the live PR. Declarations cannot be replayed after removal, and reporting failures preserve an existing Tempo verdict.

Bitbucket Pipelines

templates/bitbucket-pipelines.yml runs the same commands in Bitbucket Pipelines. The CLI reads BITBUCKET_* instead of the GitHub context (src/ci-context.ts) and differs in these ways:

• Identity. The step sets oidc: true. The CLI sends BITBUCKET_STEP_OIDC_TOKEN together with the repo key it is used for. That token carries only workspace, repository and pipeline UUIDs. Tempo takes the commit, PR and branch from Bitbucket's pipeline record, read through the repository grant that an org member authorized in Tempo. The token cannot be re-minted, so claim, capture and report run in one step and must finish within the token's lifetime.
• Step state. The commands share a small JSON file in the step's temp dir instead of GITHUB_ENV/GITHUB_OUTPUT. It carries the capture owner token and the run's status URL.
• PR base. capture fetches origin/$BITBUCKET_PR_DESTINATION_BRANCH and then computes the merge-base.
• Declarations. Bitbucket has no labels, so there is no bypass. For a PR, capture first asks Tempo whether the live PR description contains <!-- tempo-no-visual-change -->. If it does, Tempo posts success and nothing is captured.
• Status and approvals. Tempo posts the visual-review build status. Approvals are scoped to the exact head commit, so a new push needs a new approval.
• Sticky comment. report writes a markdown comment, authenticated with TEMPO_VISUAL_REVIEW_BITBUCKET_TOKEN. This is a repository access token with pull-request write access, stored as a secured repository variable. Without it the comment is skipped.
• Merge blocking. Blocking merges needs the Tempo custom merge check (tempo-modules/bitbucket-merge-check) on a plan with custom merge checks (Premium). "Minimum successful builds" counts any build status, so it is not an exact "Tempo approved" requirement.

Releases and rollback

Every production release publishes this package at the app version under latest; staging releases publish under next. Workflows resolve latest, so a bad publish is undone in seconds, without a release:

npm dist-tag add @tempo-ai/visual-review@<previous version> latest