Integrating performance testing into your GitLab CI/CD pipeline ensures that every code change is validated against your performance requirements before it reaches production. With Gatling Enterprise Edition and the official GitLab runner image, you can trigger a simulation, block the pipeline on its result, and surface pass/fail outcomes directly in merge request pipelines — without writing custom shell scripts.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt
Use this file to discover all available pages before exploring further.
Running simulations from GitLab CI/CD requires a Gatling Enterprise Edition account. Explore plans if you don’t have one yet.
Prerequisites
- Gatling version 3.13 or higher
- A Gatling Enterprise Edition account
- The sample project from gatling/devrel-projects — navigate to
articles/gitlabintegration
Step 1: Write the Simulation
Create a simple scenario that exercises your application. The example below targets an e-commerce demo site and checks that at least 90% of requests succeed.Step 2: Deploy to Gatling Enterprise Edition
Generate an API token
In Gatling Enterprise Edition, navigate to API Tokens and create a token with at minimum the Configure permission.
Create a simulation in the UI
In Simulations, click Create New, select your package, configure load generator locations and sizes, then save.
Step 3: Store the API Token in GitLab CI/CD Variables
Open CI/CD settings
In your GitLab project, go to Settings → CI/CD and expand the Variables section.
Step 4: Configure the GitLab Pipeline
Add the following.gitlab-ci.yml to the root of your repository. The pipeline uses the official gatlingcorp/enterprise-runner Docker image which includes the gatlingEnterpriseStart command.
test_00000000000000000000000000 with the simulation ID you copied earlier.
Optional: Trigger from Merge Requests
To run load tests automatically when a merge request targetsmain, add a rule:
Optional: Pass Extra Parameters to the Simulation
UseEXTRA_ENV_VARS to forward CI pipeline variables (branch name, commit SHA, environment) into the Gatling simulation for tagging and reporting purposes.
Step 5: Run the Pipeline
Once the.gitlab-ci.yml is committed, push a change or trigger the pipeline manually from CI/CD → Pipelines → Run pipeline. The job log streams the simulation status and prints a direct link to the live Gatling Enterprise Edition report. The job exits with a non-zero code if the simulation’s assertions fail, blocking any downstream deployment jobs.
Pipeline Architecture Diagram
Key Benefits
- No custom scripts — the
enterprise-runnerimage handles authentication, simulation start, and polling. - Assertion-driven gates — your performance requirements are enforced as code, not manual review.
- Unified history — every pipeline run is recorded in Gatling Enterprise Edition, enabling trend analysis across releases.