Skip to main content
A GitLab environment represents a deployment target for your application, such as development, staging or production. A deployment job — a job carrying the environment keyword — creates a deployment under that environment when it succeeds. QA Wolf receives those deployments through the connected integration, and a trigger decides which flows run for each one.

​
Requirements

  • Access to a QA Wolf workspace with at least one environment
  • Maintainer access to the GitLab group that owns the project

​
Connect GitLab

1

Create a group access token

The token needs the Maintainer role and the api scope. QA Wolf refuses anything lower, because a lesser role cannot create the webhooks it reads deployments from.
2

Enable the GitLab integration

Paste the token into Workspace settings → Integrations. QA Wolf can then read deployments, set commit statuses, and link runs to GitLab commits.

​
Give your deployment job an environment

A deployment job needs nothing beyond the environment keyword. GitLab creates the deployment itself, and the webhook fires when the job succeeds.
  • name — QA Wolf matches it against the workspace’s environments by alias or by slugified name, and creates a new environment when nothing matches. See Deployments.
  • url — the address QA Wolf runs against.
A GitLab deployment carries no slot for per-deploy environment variables, so runs against it use the QA Wolf environment’s own variables. To vary them per deploy, report the deploy through the Webhook path instead.

​
Review apps

For PR testing, a review app names its environment and url per merge request. GitLab has no transient flag, so the review/ prefix is what marks the environment as a preview; a preview named under any other prefix is created as a permanent environment.

​
Create a trigger

A connected integration starts no runs on its own. Create a deployment trigger whose conditions match the deployments your jobs now create. See Triggers.
Last modified on September 22, 2026