Source Control

Verify reads a pull or merge request's changed files, selects the relevant product journeys, and tests a ready preview of its exact source commit. It maintains one results comment and a check or status on the request. In Verify, select PR #45 or MR !45, tagged with its source repository, to open its complete run history.

Choose your source provider

Each provider has its own connection, preview discovery, CI helper, and merge-protection setup. Configure the connected repository in Verify → Integrations.

PR Testing lives in each project's sidebar. Open Projects → your project → PR Testing to configure its GitHub or GitLab source connection and preview setup. Global source integration links let you choose a project; a single active project opens directly.

How saved Runs verify a PR

Each PR can use any of the project's saved Runs. For each new PR revision, Verify compares its title, description, changed paths, and patch excerpts with the saved Scenario names, steps, and expected outcomes. It selects existing definitions and records a reason for each choice; it does not rewrite their steps or expected outcomes. Archived definitions are excluded.

Incomplete or uncertain coverage stays untested. If selection is unavailable, Verify blocks the request without launching browsers. A project with no saved Scenarios is blocked rather than reported as passing. Each execution saves its definition snapshots, so later edits do not change earlier results.

Browsers sign in to previews with the project's credentials, as they do in every other environment in the project. Discovery and saved tests can use a preview as soon as it is registered for a PR or branch. A login URL on the template's origin is adjusted to the preview origin; external identity-provider login URLs stay unchanged.

The PR page and results comment show the selected names and reasons, execution status, and a link to results. Scenario executions also appear in each Scenario's Run History. Project Scenarios are the source of PR coverage.

GitHub

Configure GitHub pull requests. Connect the Composal GitHub App, choose who builds previews, and turn on PR testing. Use composalai/verify@1 for GitHub Actions.

GitLab

Configure GitLab merge requests. Connect and import a GitLab.com project, choose CI previews or GitLab Review App discovery, and enable automatic verification. The GitLab CI helper requests verification and waits for its verdict after your deployment is ready.

Choose who builds previews

Verify tests the request's deployed source commit. Setup asks Who Builds Your PR Previews? (or MR). Choose the answer that fits your existing deployment workflow:

Save project Scenarios and a Verify environment before turning on testing. An external environment template carries personas, credential references, and safety policy to each preview URL. Follow scenario setup, credentials, and preview hosting.

Select the affected product journeys

Verify compares changed paths and available hunks with saved Scenario names, steps, and outcomes, then pins the source head, base, and selection. It selects relevant Scenarios at confidence 0.7 or higher and records reasons. Uncertain coverage and unavailable actors remain untested. One grouped Run executes the selected Scenarios in parallel within account and organization limits. A pass covers those selected journeys on that exact preview.

Use Limits → Skip PRs That Only Change for explicit exclusions, such as docs/** and README.md, one per line or separated by commas. Verify skips only when every changed path matches, including a renamed file's previous path. Leave the field empty to assess all changes.

PR and MR runs automatically use the organization’s maximum browser parallelism, up to 50 browsers per run. The limit includes plan allowances, add-ons, and administrator overrides. Other active runs share that capacity, so scenarios wait when all slots are occupied. New runs pick up changes to the organization limit; an existing run keeps the limit captured when it was prepared. Use Limits → Time Limit (Minutes) to set the execution deadline.

Run from CI or the com CLI

Use GitHub CLI commands or GitLab CLI commands to request and inspect runs. Local use starts with com login; CI reads its administrator token from COMPOSAL_API_TOKEN and uses explicit organization and repository slugs.

Hand off a ready CI preview

Deploy the full source head SHA and confirm readiness before submitting a target. Use the GitHub Action, GitLab CI helper, or the provider's CLI preview command. Keep the preview alive until execution and cleanup finish.

The helpers wait by default and report the verification verdict to CI. A successful CLI submission means Verify accepted the request; inspect its final outcome before using it as a merge gate. Verify refuses a stale commit. It does not substitute an older deployment or a shared environment when a matching preview is unavailable.

Review results, recordings, and feedback

Verify maintains one PR comment or MR note showing the tested commit, preview, each scenario's result, and why those scenarios were selected. It lists findings by priority (P0 to P4), with what was expected and what happened. Each finding links to its browser recording and to Fix with agent, which opens a prompt for Codex, Claude Code, or Cursor with the run's failures and the com commands for reading full results.

Run a scenario again lists the available scenarios, including ones the change did not select. Each Run link opens the request in Composal with that scenario chosen. Running it requires Verify admin access. Recording and run links require access to Verify; private videos are not published as public attachments.

Open a project’s Overview to see the latest verification for its assigned pull requests. Select a PR to open its run within that project. The run shows its saved Tested revision; later commits do not change that identity. The overview lists five requests initially; Show All reveals up to the 25 most recently updated requests. Requests without a verification show Not Run, and results from an older commit are marked Earlier Revision.

Verification History opens all requests for the PR or MR, newest first, with their tested commits, outcomes, setup reasons, and links to available runs. Use Previous and Next to browse older requests.

In Verify → Runs, select the repository-tagged PR #45 or MR !45, then open Verification History. Open a browser run for Live, Recordings, findings, and feedback. Earlier revisions, skipped requests, and setup blockers remain visible without being mistaken for current coverage.

Configure merge protection in your source provider: require the GitHub check, or require successful GitLab pipelines with the Verify job blocking.

Resolve setup problems

Check the provider connection, configuring user's administrator access, saved project Scenarios, environment credentials, and exact deployed source commit. The provider guides cover GitHub setup problems and GitLab setup problems, including unavailable previews, missing comments, token access, and CI timeouts.

Relevant scenarios and live progress

PR testing matches the change to your saved scenarios and prepares only matches with at least 70% relevance confidence. Large source patches use a bounded list of filenames. Scenarios without a confident match remain untested; a skipped request does not represent a passing browser test.

Each run shows the selected scenarios and their reasons, then browser planning, worker startup, execution, and evidence cleanup. Active pages update every two seconds, and browser plans appear as they finish.

For a later commit, Verify can compare against a previous successfully tested commit on the same PR base. Unaffected anonymous scenarios with unchanged inputs retain links to their previous passing evidence; they are not marked as newly executed on the new commit. Changed definitions, personas, access, project settings, or an unavailable commit comparison require fresh selection.