Is there a way to programmatically set the Indicator levels without changing the property file? I share the Gatling instance with other teams, and different scenarios have different SLAs, so I’d like to adjust the Indicator timings to be set accordingly.
For example, the default is t < 200ms = green, 200ms < t < 500ms = yellow, t > 500ms = orange, however, for one of my scenarios, I’d like it to be t < 1000ms = green, 1000ms < t < 1500ms = yellow, t > 1500ms = orange… but another scenario would have different values.
System props. See Typesafe config doc.
Thanks Stéphane… I tried this:
val conf = ConfigFactory.load()
.withValue(“gatling.charting.indicators.lowerBound”, ConfigValueFactory.fromAnyRef(1000))
.withValue(“gatling.charting.indicators.higherBound”, ConfigValueFactory.fromAnyRef(1500))
But it didn’t take… I’m assuming I need to load the “conf” object back into something? I looked around and didn’t see anything obvious that takes a Config object before running the scenario.
You didn’t get me.
Let’s say you have a HCON file:
{
foo {
bar: baz
}
}
You can override with a System prop like like: -Dfoo.bar=qix
Just override the values in gatling.conf.
Ah, sorry Stéphane. Thanks for the clarification. The problem I have is that I share a Gatling instance all triggered by a shared Jenkins job and we don’t have the ability to set environment variables arbitrarily as of yet. I was thinking I could simply change some of those properties programmatically within my test so that I wouldn’t need update a config file or set an environment variable. No worries if it’s not possible, I’ll find some way to get the environment variables option working and go from there! Thanks!
Well, Jenkins can very well be configured (and rather easily) to allow jos to be run with arbitrary environment variables.
This is, IMO, te simplest, cleanest and most flexible way to achieve what you want.
Even if you could set the indicators bounds th
Sorry, sent the last message a bit too fast 
Even If you could change those values through code, this means that you’d need to change your code every time you may want to adjust those values.
Using environment variables, it’s only a matter of running the job with a different set of parameters.
I know, but I share the Jenkins job (we pass to it specific parameters that trigger the job to execute the tests). Currently, the design doesn’t allow us to pass in arbitrary variables when executing the job and I don’t manage the Jenkins instance that we all share for performance testing. So, I’ll work separately with that team to see what we can do, but was hoping to have an interim solution where I can simply change those parameters programmatically.
Don’t even try, you can’t change the configuration programmatically.
It’s loaded before the Simulation, and it’s immutable.
Ok. Thanks Stéphane. I’ll work on getting the other team to provide a way to pass those in as environment variables. Thanks!