# Source Control Connect GitHub or GitLab to Verify. Configure preview deployments, select affected user journeys, and review browser test evidence on pull or merge requests. 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](/docs/verify/pr-testing). Connect the Composal GitHub App, choose who builds previews, and turn on PR testing. Use [`composalai/verify@1`](/docs/verify/source-control/github#github-action) for GitHub Actions. ### GitLab [Configure GitLab merge requests](/docs/verify/source-control/gitlab). 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: | Answer | How the preview becomes ready | | --- | --- | | **A Hosting Service** (GitHub) | Composal finds a successful, non-production [GitHub deployment](/docs/verify/pr-testing/github-deployment) for the exact PR head SHA, or a ready preview link in a [bot comment](/docs/verify/pr-testing/pr-comments). It looks at recent PRs to fill this in for you. | | **GitLab Review Apps** | Discover an available, non-production GitLab environment with a successful latest deployment for the exact MR source SHA. | | **My CI** | Your pipeline deploys the source commit, waits for readiness, and supplies the URL or a ready Verify preview environment. Both providers have a CI helper. | | **Composal** | Verify deploys an existing hosted-app preview profile and waits for healthy services and the entry URL. The source commit must be available in the connected Composal repository. | 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](/docs/verification#expectations-as-code), [credentials](/docs/verify/credentials), and [preview hosting](/docs/hosting#previews). ## 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](/docs/verify/source-control/github#cli) or [GitLab CLI commands](/docs/verify/source-control/gitlab#cli) 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](/docs/verify/source-control/github#github-action), [GitLab CI helper](/docs/verify/source-control/gitlab#gitlab-ci), 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](/docs/verify/source-control/github#results), or require successful [GitLab pipelines with the Verify job blocking](/docs/verify/source-control/gitlab#results). ## 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](/docs/verify/source-control/github#troubleshooting) and [GitLab setup problems](/docs/verify/source-control/gitlab#troubleshooting), 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.