Migrating to FrontLine - changes required?

Gatling (Open-Source)
1

My manager is looking to get approval to use FrontLine. YAY!

In anticipation of approval, I wanted to ask a few (hopefully) quick and easy questions.

ENVIRONMENT VARIABLES

My project defines standard simulation templates that follow a basic injection pattern, with the parameters being controlled by environment variables. Those environment variables are ingested using TypeSafe Config, using the pattern of defining the default value, and then overriding that value from the environment, if specified, like so:

test {
environment = “QA”
environment = ${?GATLING_ENVIRONMENT}
. . .
}

I don’t see a place for setting “environment variables” in the FrontLine docs, but I do see a place for setting System Properties. It’s not clear from the TypeSafe Config docs, but it looks like if I set a system property named “GATLING_ENVIRONMENT”, that would work the same way. Is that right? It also looks like I could specify the system property as “test.environment” and get the same result, yes? What would be the recommended best practice?

INTEGRATION TESTS

I use the sbt plugin, and so I launch simulations locally using sbt “gatling-it:testOnly $GATLING_SIMULATION”. I didn’t see any references to src/main vs. src/test vs. src/it in the FrontLine docs, just that you input the simulation package/class name. I did notice the docs for sbt had a command sbt test:assembly which made me suspicious that if my simulation is in the src/it folder, it might not work with that command. Is the command different for simulations in the src/it folder, e.g. sbt gatling-it:assembly? Or am I going to have to change my directory structure to work with FrontLine?

RESOURCE SYMLINKS

I make use of symlinks in my resources folder. So far, everything works great, so I’m assuming that when the files are copied, the symlinks are dereferenced and the contents are stored in the .jar file, and not a symlink. Is the same thing true for the sbt *:assembly command? Or am I going to have problems working with symlinks in the resources folder?

ANYTHING ELSE?

Are there any other migration quirks I need to be aware of?

Thanks in advance for your help!

2

My manager is looking to get approval to use FrontLine. YAY!

Great!

ENVIRONMENT VARIABLES

but it looks like if I set a system property named “GATLING_ENVIRONMENT”, that would work the same way.

Indeed

It also looks like I could specify the system property as “test.environment” and get the same result, yes?

Yes

What would be the recommended best practice?

Basically, you’re remapping an env var to a different config property name.
It only makes sense if you don’t have control over the env var name.
Otherwise, it looks more simple to me to not do that.

Why don’t you just define default values in your file, and have them overridden with env vars or system props?

test {
environment = “QA”
. . .

}

INTEGRATION TESTS

I use the sbt plugin, and so I launch simulations locally using sbt “gatling-it:testOnly $GATLING_SIMULATION”. I didn’t see any references to src/main vs. src/test vs. src/it in the FrontLine docs, just that you input the simulation package/class name. I did notice the docs for sbt had a command sbt test:assembly which made me suspicious that if my simulation is in the src/it folder, it might not work with that command. Is the command different for simulations in the src/it folder, e.g. sbt gatling-it:assembly? Or am I going to have to change my directory structure to work with FrontLine?

Indeed you won’t be able to use the default command for sbt.
Should be like it:assembly but you probably have to edit some configuration.
Honestly, sbt is really intended for Scala devs who can hack their way around.

RESOURCE SYMLINKS

Could you please explain why you use symlinks for?
FrontLine supports 2 mechanisms for deploying test code:

  • from sources, typically cloning from a git repository => your symlinks are unlikely to work: not sure if you can push symlinks in git, and then, you’d need to have your resources also present on the FrontLine server’s filesystem
  • from binary (Nexus, Artifactory, S3): you’d have to package and publish manually, a CI pipeline would suffer from the same git clone issue as abobe

ANYTHING ELSE?

Don’t rely on paths that only on your local machine with an exploded sbt project.
Except if you deploy some sensible resources yourself on the injectors’ hosts (typically private keys), expect resources to be resolved from the classpath.
eg csv(“src/test/data.csv”) is wrong and won’t work, while csv(“data.csv”) will always work both locally and with FrontLine.