GitLab pull request testing

Use this when the change is a GitLab merge request. To run a test plan you already have, use GitLab regression testing.

Set it up

Merge request review

Automatic on a GitLab deployment, a @qa.tech comment, CI, or the API.

After merge

No preview environment. Review the merged request after the deploy job.

Mobile build

Upload the build in the merge request pipeline and pin the review to it.

What works on GitLab

Capability	GitLab
Review on a preview URL, before merge	Yes. Native deployments, a `@qa.tech` comment that includes the URL, CI, or the API.
Review after merge, with no preview URL	Yes. CI can review the merged request against staging or production after the deploy job.
Review a mobile build for that merge request	Yes. Upload the binary and call the change review API. The GitLab integration has to be connected.
Read the repository source	Yes, with code access on the mapped repository. Chat and merge request reviews clone it.
Run a regression test plan	Not from this guide. GitLab CI can call the Start Run API. See GitLab regression testing.
Block the pipeline until the review finishes	No. The merge request review posts a note. It does not fail the pipeline.

What this does not do

GitLab has no equivalent of the GitHub post-merge agent. A post-merge GitLab review tests the merged code. It does not promote tests into a regression suite.
The review does not fail the pipeline. To gate a deploy on a test plan, use GitLab regression testing.
Envoyer is not a GitLab pull request review. It only starts a test plan after a deploy.

Merge request review

Set up GitLab MR reviews

There are two independent ways to integrate GitLab with QA.tech. This path is MR Reviews. It needs a GitLab sign-in. Running a test plan from CI uses only an API key. See GitLab regression testing.

Sign in with a dedicated GitLab service user rather than a personal account. GitLab does not offer organization-wide access for what we need, and a personal account stops working if that user is removed.

Open Settings → Integrations → GitLab MR Reviews and sign in with GitLab. Use a dedicated GitLab service user rather than a personal account. GitLab does not offer organization-wide access for what we need, and a personal account stops working if that user is removed. The GitLab account is shared by every project in the organization.

Choose a repository

On the same page, choose the repository you want QA.tech to review.

Configure MR review behavior

In the GitLab integration settings, configure:

Review Context (optional instructions for reviews)
Auto-run on Merge Requests
Include Draft Merge Requests
Post Comment on Opened MR (post an introductory QA.tech comment when an MR is opened, including waiting/progress guidance)
Environment Mapping (map GitLab environments to QA.tech applications)
Code Access (on by default; see Code access)

Save integration

Saving creates or refreshes the GitLab webhook connection for your selected repository so QA.tech can process merge request, note, deployment, and pipeline events.

What a review does on every CI is on How a review works. When enabled, QA.tech can:

detect merge request activity from your connected repository
post an introduction or progress comment on merge requests
run exploratory and end-to-end testing against your merge request
publish a final results-based review comment back on the merge request

What QA.tech posts on GitLab MRs

QA.tech posts comments and review notes on merge requests when the integration is triggered.

Operation	When	Description
MR comment (in progress)	When the agent starts testing	Comment with link to the QA.tech conversation and details (project, MR number, branch, event type). Lets you track progress.
MR review note	After tests complete	MR note with verdict (Approved, Changes Requested, or Comment), summary, test results table, and evaluation details.

QA.tech uses your connected GitLab OAuth integration to call GitLab APIs. That means MR comments and review updates are posted through your connected GitLab integration identity.

Automatic MR review triggering requires native GitLab deployment and environment signals. If your flow does not publish those signals, use the manual or CI-assisted @qa.tech trigger path in Triggering a merge request review.

Triggering a merge request review

Option A: Automatic trigger for native GitLab deployments

If Auto-run on Merge Requests is enabled, QA.tech can auto-trigger reviews when deployment data is ready from native GitLab deployments and environments. High-level behavior:

MR is opened or updated.
QA.tech checks if the MR commit is the latest and deployment(s) for that commit are ready.
If deployments are ready, QA.tech starts the review flow automatically.
If deployments are not ready, QA.tech can post a waiting comment (based on your setting) and wait for deployment readiness or a manual @qa.tech trigger.

Option B: Manual trigger using a GitLab comment

Comment on the merge request and mention @qa.tech. Include the preview deployment URL in the same comment. QA.tech parses URLs from MR comments and uses that URL as deployment context for the review run. In practice, this is required for reliable review targeting. Example:

@qa.tech https://preview.example.com

Option C: CI-assisted manual trigger

If your deployment process is custom, have CI post an MR comment that mentions @qa.tech and includes the preview URL. This gives you a consistent trigger pattern without requiring developers to comment manually each time.

Option D: API trigger (no `@qa.tech` comment)

Trigger the same MR review directly from CI by calling the Start change review chat API with mode: "pr". This runs the same review agent as Options A, B, and C and posts the same native MR review note, but you control exactly when it fires and which environment it targets, with no @qa.tech comment required. This requires the repository to be connected in Settings → Integrations → GitLab so the agent can read the MR and post the review note.

qatech_mr_review:
  stage: test
  only:
    - merge_requests
  script: |
    MR_URL="${CI_MERGE_REQUEST_PROJECT_URL}/-/merge_requests/${CI_MERGE_REQUEST_IID}"
    curl -sSf -X POST "https://api.qa.tech/v1/chat/change-review" \
      -H "Authorization: Bearer ${QA_TECH_API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "{
        \"mode\": \"pr\",
        \"prUrl\": \"${MR_URL}\",
        \"vcsProviderId\": \"gitlab\",
        \"applicationOverrides\": [{
          \"applicationShortId\": \"${QATECH_APP_SHORT_ID}\",
          \"environment\": { \"url\": \"${PREVIEW_URL}\" }
        }]
      }"

The review runs asynchronously; poll Get chat conversation if you want CI to wait for the verdict. See Start change review chat API for the full request schema.

Use this same API for post-merge reviews when you do not have per-MR preview environments. See After merge.

Troubleshooting

No review starts after MR open

Verify the repository is selected in GitLab integration settings.
Check whether Auto-run on Merge Requests is enabled.
Confirm deployment status is successful for the latest MR commit, or manually trigger with @qa.tech.
If you are not using native GitLab deployment/environment signals, use the manual @qa.tech trigger with a preview URL.

Draft MRs are skipped

Enable Include Draft Merge Requests if you want draft MRs reviewed.

Manual trigger did nothing

Make sure the comment is on the merge request and includes @qa.tech (case-insensitive).
If you expect preview-aware testing, include the preview URL in that same comment.

Chat or reviews cannot search source code

Open the repository under Settings → Integrations → GitLab MR Reviews and turn on Code Access. See Code access.

Code access

Code Access is on by default when you add a repository. When it is on, chat and merge request reviews clone the mapped repository and search its source when the knowledge graph or the merge request diff is not enough.

The clone uses the connected GitLab account, so that account needs at least read access to the repository.
Only repositories mapped on the GitLab page with Code Access on are cloned. With several mapped, name the repository in chat. A review uses the merge request’s repository.
Turning it on starts an analysis of the repository. It adds a Code gating facts item for the repository to Settings → Knowledge → Library. Its status appears under the toggle.
Turn Code Access off and save to stop cloning. Knowledge items already in the library stay until you remove them.

Code access works for repositories on gitlab.com.

After merge

If you do not have preview environments for merge requests, you can run QA.tech change reviews after merging to your main branch. This tests the changes from each MR against your staging or production environment once they’re deployed.

Before you start

Connect the repository in Settings → Integrations → GitLab, so the agent can read the merged MR and post the note.
Create your staging environment in Settings → Applications & Envs with the URL your deploy job publishes to. Copy the application short ID (for example app_abc123) and the environment short ID (three-dot menu → Copy Short ID, for example env_abc123).
Make sure QA.tech can reach staging. If it is private, behind a VPN, or behind basic auth, see Environment access.
Create an API token in Organization Settings → API Keys.

The job below passes the environment short ID, and the agent tests the URL saved on that environment in QA.tech. If the staging URL changes, update the environment in QA.tech, not the job. To test a URL that is not saved as an environment, pass url instead of shortId in environment.

How it works

An MR is merged to main/dev/staging.
Your deploy job deploys to staging/production.
CI extracts the MR number from the merge commit message.
The agent fetches the MR details (diff, changed files, description).
Tests run against your deployed environment.
Results are posted back on the merged MR as a note.

stages:
  - deploy
  - review

deploy:
  stage: deploy
  only:
    - main
  script:
    - echo "Your deploy steps..."

change-review:
  stage: review
  needs: [deploy]
  only:
    - main
  script: |
    MR_IID=$(echo "$CI_COMMIT_MESSAGE" | grep -oE '![0-9]+' | tail -1 | tr -d '!')
    if [ -z "$MR_IID" ]; then
      echo "No MR number found in commit message, skipping"
      exit 0
    fi
    MR_URL="${CI_PROJECT_URL}/-/merge_requests/${MR_IID}"
    curl -sSf -X POST "https://api.qa.tech/v1/chat/change-review" \
      -H "Authorization: Bearer ${QA_TECH_API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "{
        \"mode\": \"pr\",
        \"prUrl\": \"${MR_URL}\",
        \"vcsProviderId\": \"gitlab\",
        \"applicationOverrides\": [{
          \"applicationShortId\": \"${QATECH_APP_SHORT_ID}\",
          \"environment\": { \"shortId\": \"${QATECH_STAGING_ENV_SHORT_ID}\" }
        }],
        \"context\": \"This MR has already been merged and deployed. Test the changes and report any issues found.\"
      }"

Setup

Add QA_TECH_API_TOKEN, QATECH_APP_SHORT_ID, and QATECH_STAGING_ENV_SHORT_ID as CI/CD → Variables (mark the token Protected and Masked).
Set QATECH_APP_SHORT_ID to your application’s short ID (for example app_gXeBl2).
Set QATECH_STAGING_ENV_SHORT_ID to the staging environment’s short ID (for example env_abc123).
Make sure the change-review job runs after your deploy job completes (needs: [deploy]).

Notes

GitLab’s default merge commit message ends with See merge request namespace/project!123. The script extracts the last !<number> token, so it assumes the MR reference is at the end of the message.
If you use squash merges with a custom template, include %{reference} in the template so the MR reference is present in the commit message.
We extract the MR number from the commit message because CI_MERGE_REQUEST_IID is only set in merge request pipelines, not on push-to-main.
Direct pushes to main without an MR are skipped automatically.
Results are posted back on the merged MR as a note, since the MR is already merged.

No MR reference in your commits? Use mode: "rawChanges" instead and pass a changes object with changeDescription and a git diff computed in CI. See the Start Change Review Chat reference.

Set it up with the MCP

With the QA.tech MCP server connected in your editor, your coding agent can look up the IDs and write the job. Open the repository and paste:

Add a QA.tech after-merge change review to this repository's
.gitlab-ci.yml.

1. Find the job that deploys the default branch, and the
   staging URL it deploys to.
2. With the QA.tech MCP, call list_projects,
   list_applications, and list_application_environments to
   find the application short ID and the environment short
   ID whose URL matches staging.
3. If no environment matches, call create_chat with: "Create
   an environment named Staging with URL <staging URL> for
   application <application short ID>, check that QA.tech
   can reach it, and tell me whether <repository URL> is
   connected to the GitLab integration." Poll
   get_chat_conversation until its status is completed, then
   list the environments again.
4. Read https://docs.qa.tech/pr-testing/gitlab#after-merge
   and add the change-review job after the deploy job.
5. Tell me which CI/CD variables to add (QA_TECH_API_TOKEN,
   QATECH_APP_SHORT_ID, QATECH_STAGING_ENV_SHORT_ID), and
   anything still missing in QA.tech.

Mobile build

Store QA_TECH_API_TOKEN as a CI/CD variable. Upload the build, then start a change review. Change reviews need the repository connected under Settings → Integrations → GitLab.

qatech_mobile_mr:
  stage: test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: |
    APP_ID="app_gXeBl2"
    BUILD_FILE="app/build/outputs/apk/debug/app-debug.apk"
    FILE_NAME=$(basename "$BUILD_FILE")

    UPLOAD_RESPONSE=$(curl -sSf -X POST "https://api.qa.tech/v1/applications/$APP_ID/builds/upload-url" \
      -H "Authorization: Bearer $QA_TECH_API_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{\"fileName\": \"$FILE_NAME\"}")
    UPLOAD_URL=$(echo "$UPLOAD_RESPONSE" | jq -r '.uploadUrl')
    BUILD_TOKEN=$(echo "$UPLOAD_RESPONSE" | jq -r '.buildToken')
    curl -sSf -X PUT "$UPLOAD_URL" \
      --upload-file "$BUILD_FILE" \
      -H "Content-Type: application/octet-stream"
    BUILD_RESPONSE=$(curl -sSf -X POST "https://api.qa.tech/v1/applications/$APP_ID/builds" \
      -H "Authorization: Bearer $QA_TECH_API_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{\"platform\": \"android\", \"buildToken\": \"$BUILD_TOKEN\"}")
    BUILD_SHORT_ID=$(echo "$BUILD_RESPONSE" | jq -r '.applicationBuildShortId')

    MR_URL="${CI_MERGE_REQUEST_PROJECT_URL}/-/merge_requests/${CI_MERGE_REQUEST_IID}"
    curl -sSf -X POST "https://api.qa.tech/v1/chat/change-review" \
      -H "Authorization: Bearer $QA_TECH_API_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{
        \"mode\": \"pr\",
        \"prUrl\": \"$MR_URL\",
        \"vcsProviderId\": \"gitlab\",
        \"applicationOverrides\": [{
          \"applicationShortId\": \"$APP_ID\",
          \"environment\": { \"applicationBuildShortId\": \"$BUILD_SHORT_ID\" }
        }]
      }"

To run a fixed plan instead of a change review, call Start Run with testPlanShortId and the same applications override. Poll Get Run if the job should fail on test failure. See GitLab regression testing.

PR Testing

Agents

Choose your CI

GitLab pull request testing

Set it up

Merge request review

After merge

Mobile build

What works on GitLab

What this does not do

Merge request review

Set up GitLab MR reviews

What QA.tech posts on GitLab MRs

Triggering a merge request review

Option A: Automatic trigger for native GitLab deployments

Option B: Manual trigger using a GitLab comment

Option C: CI-assisted manual trigger

Option D: API trigger (no `@qa.tech` comment)

Troubleshooting

Code access

After merge

Before you start

How it works

Setup

Notes

Set it up with the MCP

Mobile build

​Set it up

Merge request review

After merge

Mobile build

​What works on GitLab

​What this does not do

​Merge request review

​Set up GitLab MR reviews

​What QA.tech posts on GitLab MRs

​Triggering a merge request review

​Option A: Automatic trigger for native GitLab deployments

​Option B: Manual trigger using a GitLab comment

​Option C: CI-assisted manual trigger

​Option D: API trigger (no @qa.tech comment)

​Troubleshooting

​Code access

​After merge

​Before you start

​How it works

​Setup

​Notes

​Set it up with the MCP

​Mobile build

Set it up

What works on GitLab

What this does not do

Merge request review

Set up GitLab MR reviews

What QA.tech posts on GitLab MRs

Triggering a merge request review

Option A: Automatic trigger for native GitLab deployments

Option B: Manual trigger using a GitLab comment

Option C: CI-assisted manual trigger

Option D: API trigger (no `@qa.tech` comment)

Troubleshooting

Code access

After merge

Before you start

How it works

Setup

Notes

Set it up with the MCP

Mobile build