Contact UsGet started
© 2025 Direct Cursus Technology L.L.C.

Invoking load testing from GitLab CI

Written by
Updated at August 14, 2025

GitLab is a web-based Git repository management site and system. GitLab also lets developers run a continuous process for writing, testing, and deploying code.

In this scenario, you will use Yandex Load Testing to add the stage of invoking a load test of the application being deployed to the continuous integration and continuous delivery (CI/CD) pipeline. During this stage, the script will create a test agent, run the test, and check the test result.

To add the load testing invocation from GitLab CI:

  1. Get your cloud ready.
  2. Set up your infrastructure.
  3. Prepare a file with test data.
  4. Create GitLab environment variables.
  5. Add the load testing stage to the CI scenario configuration file.

If you no longer need the resources you created, delete them.

Get your cloud ready

Sign up for Yandex Cloud and create a billing account:

  1. Navigate to the management console and log in to Yandex Cloud or create a new account.
  2. On the Yandex Cloud Billing page, make sure you have a billing account linked and it has the ACTIVE or TRIAL_ACTIVE status. If you do not have a billing account, create one and link a cloud to it.

If you have an active billing account, you can navigate to the cloud page to create or select a folder for your infrastructure.

Learn more about clouds and folders here.

  1. If the agent is hosted on Yandex Cloud, you pay for computing resources (see Yandex Compute Cloud pricing).

  2. Fee for data storage in a bucket and data operations (see Object Storage pricing).

Set up your infrastructure

Create a service account

  1. Create a service account named sa-loadtest in the folder that will host the agent to generate the load.

  2. Assign the following roles to the service account:

    • loadtesting.generatorClient
    • loadtesting.loadTester
    • iam.serviceAccounts.user
    • compute.editor
    • vpc.user
    • vpc.publicAdmin (optionally, if you are deploying the agent in a public network)

  3. Create an authorized key for this service account and save it to the key.json file.

Configure your network

Create and configure a NAT gateway in the subnet hosting your test target and where the agent will reside. This will enable the agent to access Load Testing.

Configure the security group

Configure the test agent security group:

  1. Create an agent security group named agent-sg.
  2. Add rules:

    1. Rule for outbound HTTPS traffic to the Load Testing public API:

      • Port range: 443.
      • Protocol: TCP.
      • Destination name: CIDR.
      • CIDR blocks: 0.0.0.0/0.

      This will allow you to connect the agent to Load Testing to manage tests from the interface and get test results.

    2. Inbound SSH traffic rule:

      • Port range: 22.
      • Protocol: TCP.
      • Destination name: CIDR.
      • CIDR blocks: 0.0.0.0/0.

      This will allow you to connect to the agent over SSH and manage tests from the console or collect debugging information.

    3. Rule for outbound traffic when generating load to the test target:

      • Port range: 0-65535.
      • Protocol: Any.
      • Destination name: Security group.
        Select From list. Specify the security group comprising the test target.

      Create this rule for each test target with a unique security group.

Prepare a CI/CD pipeline in GitLab for deploying the test target

In this tutorial, we will use an application with the 51.250.103.44 public IP address as the test target. For an example of building a CI/CD pipeline in GitLab, see this article.

Prepare a file with test data

  1. Generate test data in HTTP_JSON format:

    {"host": "51.250.103.44", "method": "GET", "uri": "/", "tag": "url1", "headers": {"User-agent": "Tank", "Connection": "Close"}}

    Where:

    • host: Host header value.
    • method: HTTP request method.
    • uri: Request URI.
    • tag: Request tag for use in reports.
    • headers: Request headers.

You can also use the Dispatcher tool to prepare test data.

  1. Save the test data to a file named httpjson.payload.

  2. Create a bucket and upload the test data file into it.

  3. Grant read permissions for the bucket to the service account. To do this, edit the bucket ACL:

    1. In the management console, select the folder with the bucket.
    2. In the list of services, select Object Storage.
    3. Click next to the bucket and select Configure ACL.
    4. In the window that opens, enter the service account name, select READ for the bucket permissions, and click Add.
    5. Click Save.

    The service account will get read permissions only for this bucket.

Create GitLab environment variables

  1. In GitLab, navigate to Settings in the left-hand panel and select CI/CD from the drop-down list.

  2. Click Expand next to Variables.

  3. Add environment variables with the protection option disabled:

    • SERVICE_ACCOUNT_ID: sa-loadtest service account ID.
    • SA_AUTHORIZED_KEY: Contents of the authorized key for the sa-loadtest service account.
    • SECURITY_GROUP_ID: Test agent's agent-sg security group ID.
    • SUBNET_ID: ID of the subnet to host the test agent.
    • ZONE: Availability zone to host the test agent, e.g.,ru-central1-a.
    • YC_FOLDER_ID: ID of the folder to host the resources.

    To add a variable:

    1. Click Add variable.
    2. In the window that opens, specify the variable name in the Key field and its value in the Value field.
    3. Disable the Protect variable option.
    4. Click Add variable.

Add the load testing stage to the CI scenario configuration file

  1. Add the test-config.yaml load testing configuration file to your project repository in GitLab:

    pandora:
   enabled: true
   package: yandextank.plugins.Pandora
   config_content:
      pools:
         - id: HTTP
         gun:
            type: http
            target: 51.250.103.44
            ssl: false
         ammo:
            type: http/json
            file: httpjson.payload
         result:
            type: phout
            destination: ./phout.log
         startup:
            type: once
            times: 1000
         rps:
            - type: line
               from: 0
               to: 500
               duration: 60s
         discard_overflow: true
      log:
         level: error
      monitoring:
         expvar:
            enabled: true
            port: 1234
autostop:
   enabled: true
   package: yandextank.plugins.Autostop
   autostop:
      - limit(5m) # Required parameter
      - quantile(50,100,5,)
core: {}

    In the target field, enter the address of your application. This testing configuration will generate a linear load from 0 to 500 requests per second for 60 seconds. The autostop criterion is also configured. This criterion will stop the test if the 50th percentile exceeds 100 milliseconds for 5 seconds.

  2. Add the load testing stage to the .gitlab-ci.yml file after deploying the application:

    stages:
   ...
   - loadtesting
   ...

loadtesting-job:
   stage: loadtesting
   allow_failure: true
   artifacts: 
      when: always
      name: "tests_output"
      paths:
         - agent_id.txt
   before_script:
      # Installing tools.
      - sudo apt-get install -y jq
      - curl --fail --silent --location --remote-name https://storage.yandexcloud.net/yandexcloud-yc/install.sh
      - sudo bash install.sh -i /usr/local/yandex-cloud -n
      - sudo ln -f -s /usr/local/yandex-cloud/bin/yc /usr/local/bin/yc
      # Authenticating with the service account key
      - echo "$SA_AUTHORIZED_KEY" > key.json
      - yc config profile create sa-profile || echo "Profile already exists"
      - yc config set service-account-key key.json
      - yc config set folder-id ${YC_FOLDER_ID}
   script:
      # Creating a test agent
      - agent_id=$(yc loadtesting agent create --name agent${CI_JOB_ID} --zone ${ZONE} --service-account-id ${SERVICE_ACCOUNT_ID} --network-interface security-group-ids=${SECURITY_GROUP_ID},subnet-id=${SUBNET_ID} --format json | jq -r .id)
      - echo $agent_id > agent_id.txt
      # Waiting for the agent to become available
      - |
        while true; do
           if ! _status=$(yc loadtesting agent get "$agent_id" --format json | jq -r '.status'); then
              sleep 10
              continue
           fi
           if [[ "$_status" == "READY_FOR_TEST" ]]; then
              echo "Agent is ready"
              break
           fi
           echo "Waiting for agent..."
           sleep 10
        done
      # Creating a configuration
      - config_id=$(yc loadtesting test-config create --from-yaml-file test-config.yaml --format json | jq -r .id)
      # Running the test
      - test_id=$(yc loadtesting test create --name "test_${CI_COMMIT_SHORT_SHA}" --description "${CI_COMMIT_MESSAGE}" --labels auto=true --configuration agent-id=$agent_id,id=$config_id,test-data=httpjson.payload --test-data name=httpjson.payload,s3bucket=payload-bucket,s3file=httpjson.payload --wait --format json | jq -r .id)
      - yc loadtesting test wait --idle-timeout 120s $test_id
      # Evaluating test results
      - q50=$(yc loadtesting test get-report-table $test_id --format json | jq -r .overall.quantiles.q50)
      - |
        if [[ $q50 -gt 100 ]]; then
           echo "Q50 exceeds 100 ms, test failed"
           exit 1
        fi
   after_script:
      # Deleting the test agent
      - agent_id=$(cat agent_id.txt)
      - yc loadtesting agent delete $agent_id
      - rm agent_id.txt

    During the stage described here, the script will create a test agent, run the test, and check the test result. The result evaluation is based on the 50th percentile. If it exceeds 100 ms, the stage will terminate with an error.

    After you save the .gitlab-ci.yml configuration file, the build scenario will start.

    You can view the test results in more detail in the management console:

    1. In the management console, select Load Testing.
    2. In the left-hand panel, select Tests.
    3. Select the test you created and navigate to the Test results tab.

    You can use any connection logic for this stage:

    • On commits to the main branch
    • On pull request updates

    For more complex scenarios, see this video:

Delete the resources you created

Some resources are not free of charge. To avoid paying for them, delete the resources you no longer need:

  1. Delete the service accounts.
  2. Delete the Object Storage bucket.
  3. Make sure that the test agent created by the script was deleted. You can delete the agent manually.
  4. Delete the route table.
  5. Delete the NAT gateway.
Previous
Getting the number of queries to Object Storage objects
Next
Deploying GitLab Runner on a Compute Cloud virtual machine