As a Gatling repository grows from one simulation to a dozen, how would you decide what each pipeline job actually launches?

A repository with one simulation has no selection problem. A repository with a dozen has one every day, and the plugins deliberately do not solve it for you: when several simulations are available and no one can be prompted, the run **fails**. Deciding what each job launches is the real design question, and there are only three shapes of answer. ## Shape 1: pin one simulation per job Each job names a class — `mvn gatling:test -Dgatling.simulationClass=com.project.simu.CheckoutSimulation`, or `./gradlew gatlingRun --simulation=com.project.simu.CheckoutSimulation`, or `sbt 'Gatling/testOnly com.project.simu.CheckoutSimulation'`. - **For:** every job is explicit and its runtime is predictable. Adding a simulation cannot change what an existing job does. - **Against:** adding a simulation changes nothing at all. A class can sit in the repository for months, compiling, reviewed, and never executed, because no job was ever wired to it. ## Shape 2: run the whole set Gradle has `gatlingRun --all`, which runs every discovered simulation sequentially in alphabetic order. sbt has `Gatling/testFull`. **Maven has no run-all switch**: `gatling:test` selects one simulation per invocation, so "all of them" there means several invocations, or several bound executions. - **For:** nothing is ever forgotten. A new simulation joins the run the moment it compiles. - **Against:** the job's meaning changes without the job changing. Runtime grows monotonically with the file count, order is alphabetic rather than meaningful, and one broken simulation affects a run that was not about it. ## Shape 3: leave the failure in place The third option is to treat the failure as the design. The day someone adds a second simulation, the job fails and a human has to say which one it means. That is not a defect to route around; it is the tool converting an ambiguity into a visible event. The anti-pattern is worth naming: reacting to "more than one simulation is available" by adding `-B`, or by setting the `CI` variable, or by unsetting it. The first two are what produced the failure; the third restores an interactive prompt on a machine with nobody to answer it. ## Where the answer should live Independently of shape, the class name can sit in two places: | Location | Example | What it buys | |---|---|---| | The build file | `<simulationClass>` in the Maven plugin, or `simulation` in the Gradle `gatling` extension | the repository is self-describing; a change to what runs shows up in a code review | | The pipeline | `-Dgatling.simulationClass=...` or `--simulation=...` per job | one build serves several jobs, each pinning a different class | Pick one per repository. Holding the same answer in both places is exactly how a job drifts away from what the build file claims, and the drift is invisible until someone reads both. ## The same decision, one level up If any job starts a run on Gatling Enterprise rather than locally, the question repeats in different vocabulary. `mvn gatling:enterpriseStart`, `./gradlew gatlingEnterpriseStart` and `npx gatling enterprise-start` all prompt you to choose from the **deployed simulations**, and all three take a way to bypass the prompt: `-Dgatling.enterprise.simulationName="<name>"` on the two JVM plugins, `--enterprise-simulation="<name>"` on the JavaScript CLI. The `CI` environment variable disables interaction there too. It is worth deciding both at once, because a repository that pins a class locally and prompts on Enterprise has only solved half the problem. ## How I would decide 1. **One simulation, one job, name it in the build file.** Small repositories get the cheapest thing that is reviewable. 2. **Several simulations that mean different things: one job each, pinned in the pipeline.** Their runtimes, their schedules and their failure owners differ, so they should not share a job. 3. **Several simulations that mean the same thing (a suite): `--all` on Gradle or `Gatling/testFull` on sbt, and accept that runtime grows.** On Maven, that becomes explicit bound executions, which is more typing but also a written list of what runs. 4. **Never work around the CI failure.** Whatever shape you choose, it should be an answer someone wrote down, not a default the tool guessed. The judgement underneath all of this is a familiar one: explicit configuration is auditable but goes stale, and discovery stays fresh but changes behaviour without a diff. Gatling gives you both levers and, unusually, a loud failure when you have picked neither.