# Source Control

Connect GitHub or GitLab to test the journeys affected by a pull or merge request.

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 keeps one results comment and check or status up to date on the request. **PR #45** or **MR !45**, tagged with its source repository in Verify, opens 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**.

The Verify sidebar also has a testing shortcut: **PR Testing** when only GitHub is connected, **MR Testing** when only GitLab is connected, and **PR & MR Testing** when both are connected. A single-provider shortcut opens that provider’s settings directly; with both providers, choose one from Integrations.

### GitHub

[Configure GitHub pull requests](/docs/verify/source-control/github). Connect the Composal GitHub App, choose a preview source, and enable automatic verification. 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 <a id="gitlab-ci" href="/docs/verify/source-control/gitlab#gitlab-ci">GitLab CI helper</a> requests verification and waits for its verdict after your deployment is ready.

## Choose a preview source

Verify tests the request's deployed source commit. Choose the source that fits your existing deployment workflow:

| Source | How the preview becomes ready |
| --- | --- |
| **Your 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. |
| **GitHub Deployment** | Discover a successful, non-production GitHub deployment for the exact PR head SHA. |
| **GitLab Environment** | Discover an available, non-production GitLab environment with a successful latest deployment for the exact MR source SHA. |
| **Composal Preview** | 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. |

Prepare a scenario pack and a Verify environment for the connected repository before enabling 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/verification#credentials), and [preview hosting](/docs/hosting#previews).

## Select the affected product journeys

Planning uses the same ownership and dependency rules as Changes. Verify compares changed paths and available hunks with the scenario pack's product areas, then pins the source head, base, and selection plan. Each run explains the selected and excluded areas.

Unknown paths, cross-cutting changes, or incomplete diffs can broaden selection to the safe set. Packs without file ownership run all planned journeys. A pass covers the selected journeys for that pinned preview.

Use **Advanced Settings → Paths That Need No Browser Testing** 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.

## 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 `VEX_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 CLI submission succeeding means the request was accepted; inspect its final outcome before using it as a merge gate. A stale commit is refused. Verify does not substitute an older deployment or a shared environment when a matching preview is unavailable.

## Review results, recordings, and feedback

One maintained PR comment or MR note shows the tested commit, preview, selection reasons, current state, and problems to address. Critical and high-severity findings link to protected issue recordings. These links require access to Verify; private videos are not published as public attachments.

In **Verify → Runs**, select the repository-tagged **PR #45** or **MR !45** to open its 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, scenario pack, 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.