Package Generation

Generate a package from your Gatling bundle or with a Maven, SBT, or Gradle project.

Generating Packages for Gatling Enterprise

Gatling Enterprise deploys packages containing your compiled Simulations and resources. Those packages have to be generated upstream, using one of the methods below, before you can run them with Gatling Enterprise.

Gatling Enterprise is compatible with Gatling 3.3, 3.4, 3.5, 3.6 and 3.7.

Gatling zip bundle

Once you have created a simulation you want to upload, run the script enterprisePackage.sh (on Linux or macOS) or enterprisePackage.bat (on Windows), found in the bin directory of your unzipped Gatling bundle. This will generate a target/package.jar file. You can then upload this file in the Packages section.

$ ./bin/enterprisePackage.sh

You can also create a package and upload it in a single command, using the script enterpriseDeploy.sh (on Linux or macOS) or enterprisePackage.bat (on Windows). You must have already configured a package (copy the package ID from the Packages table). You also need an API token with appropriate permissions to upload a package.

Run the script:

$ ./bin/enterpriseDeploy.sh --packageId YOUR_PACKAGE_ID --apiToken YOUR_API_TOKEN

Alternatively, the API token can be set with the environment variable GATLING_ENTERPRISE_API_TOKEN:

$ export GATLING_ENTERPRISE_API_TOKEN=YOUR_API_TOKEN
$ ./bin/enterpriseDeploy.sh --packageId YOUR_PACKAGE_ID

Maven, Gradle or SBT project

To set up you project, and to learn how to use you preferred build tool to upload your simulations to Gatling Enterprise Cloud, please refer to the documentation pages of the respective plugins:

Note on Feeders

A typical mistake with Gatling and Gatling Enterprise is to rely on having an exploded Maven/Gradle/SBT project structure, and to try to load files from the project filesystem.

This filesystem structure will not be accessible once your project has been packaged and deployed to Gatling Enterprise.

If your feeder files are packaged with your test sources, you must resolve them from the classpath. This will work both when you run simulations locally and when you deploy them to Gatling Enterprise.

// incorrect
val feeder = csv("src/test/resources/foo.csv")

// correct
val feeder = csv("foo.csv")

Load Sharding

Injection rates and throttling rates are automatically distributed amongst nodes.

However, Feeders data is not automatically sharded, as it might not be the desired behavior.

If you want data to be unique cluster-wide, you have to explicitly tell Gatling to shard the data, e.g.:

val feeder = csv("foo.csv").shard

Assuming the CSV file contains 1000 entries, and you run your simulation on 3 Gatling nodes, the entries will be distributed as follows:

  • First node will access the first 333 entries
  • Second node will access the next 333 entries
  • Third node will access the last 334 entries

Resolving Injector Location in Simulation

When running a distributed test from multiple locations, you could be interested in knowing where a given injector is deployed in order to trigger specific behaviors depending on the location.

For example, you might want to hit https://example.fr if the injector is deployed in the Europe - Paris AWS region, and https://example.com otherwise.

In your simulation code, you can resolve the name of the pool in which the injector running the code is deployed:

val poolName = System.getProperty("gatling.frontline.poolName")
val baseUrl = if (poolName == "Europe - Paris") "https://example.fr" else "https://example.com"

Edit this page on GitHub

← Profile
Package Configuration →