Gatling Maven Plugin Return Code

Hello all,

We’ve just started using gatling in anger, running within Jenkins.

One thing that has tripped us up a couple of times is that the maven plugin seems to be returning “success” when there are compile errors in the tests.

A log of this is attached below.

mvn is returning a 0 in this case, and the build gets flagged as successful.

Is there any way to change this behaviour?

Dave

  • mvn -f pom.xml gatling:execute -Dgatling.simulationClass=saas.SaasSimulation
    [INFO] Scanning for projects…
    [INFO]
    [INFO] ------------------------------------------------------------------------
    [INFO] Building idol-saas-gatling-tests 2.0.0-M1
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] — gatling-maven-plugin:2.0.0-M3a:execute (default-cli) @ idol-saas-gatling-tests —
    08:49:38.266 [ERROR] i.g.a.ZincCompiler$ - /var/jenkins/workspace/IOD_API_Gatling_Prod/gatling/src/test/scala/saas/Query.scala:8: Query is already defined as class Query
    08:49:38.269 [ERROR] i.g.a.ZincCompiler$ - class Query(api : ApiEndpoint) {
    08:49:38.269 [ERROR] i.g.a.ZincCompiler$ - ^
    08:49:38.278 [ERROR] i.g.a.ZincCompiler$ - one error found
    Exception in thread “main” Compilation failed
    at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:105)
    at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:48)
    at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:41)
    at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply$mcV$sp(AggressiveCompile.scala:98)
    at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
    at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
    at sbt.compiler.AggressiveCompile.sbt$compiler$AggressiveCompile$$timed(AggressiveCompile.scala:155)
    at sbt.compiler.AggressiveCompile$$anonfun$3.compileScala$1(AggressiveCompile.scala:97)
    at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:138)
    at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:86)
    at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:30)
    at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:28)
    at sbt.inc.Incremental$.cycle(Incremental.scala:73)
    at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:33)
    at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:32)
    at sbt.inc.Incremental$.manageClassfiles(Incremental.scala:41)
    at sbt.inc.Incremental$.compile(Incremental.scala:32)
    at sbt.inc.IncrementalCompile$.apply(Compile.scala:25)
    at sbt.compiler.AggressiveCompile.compile2(AggressiveCompile.scala:146)
    at sbt.compiler.AggressiveCompile.compile1(AggressiveCompile.scala:70)
    at com.typesafe.zinc.Compiler.compile(Compiler.scala:161)
    at com.typesafe.zinc.Compiler.compile(Compiler.scala:142)
    at io.gatling.app.ZincCompiler$.main(ZincCompiler.scala:111)
    at io.gatling.app.ZincCompiler.main(ZincCompiler.scala)
    java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at scala_maven_executions.MainHelper.runMain(MainHelper.java:164)
    at scala_maven_executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26)
    Caused by: org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
    at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
    at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
    at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
    at io.gatling.app.ZincCompilerLauncher$.apply(ZincCompilerLauncher.scala:54)
    at io.gatling.app.SimulationClassLoader$.fromSourcesDirectory(SimulationClassLoader.scala:32)
    at io.gatling.app.Gatling$$anonfun$15.apply(Gatling.scala:171)
    at io.gatling.app.Gatling$$anonfun$15.apply(Gatling.scala:171)
    at scala.Option.getOrElse(Option.scala:120)
    at io.gatling.app.Gatling.start(Gatling.scala:171)
    at io.gatling.app.Gatling$.fromMap(Gatling.scala:59)
    at io.gatling.app.Gatling$.runGatling(Gatling.scala:80)
    at io.gatling.app.Gatling$.main(Gatling.scala:54)
    at io.gatling.app.Gatling.main(Gatling.scala)
    … 6 more
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 6.173s
    [INFO] Finished at: Fri Oct 25 08:49:38 BST 2013
    [INFO] Final Memory: 8M/108M
    [INFO] ------------------------------------------------------------------------
    [PostBuildScript] - Execution post build scripts.

I opened an issue: https://github.com/excilys/gatling/issues/1482

What were you running before?
And why the anger?

@Floris: was also surprised the first time I heard this: http://english.stackexchange.com/questions/30939/is-used-in-anger-a-britishism-for-something :slight_smile:

Hi Floris,

This is just a quaint British expression for using something for real, rather than just “kicking the tyres” (another quaint expression).

Gatling is the first thing we have tried for functional API testing and load testing, and it’s working out well for us so far.

Dave

I’m just a bit surprised to see a hp.com email address here, given that loadrunner is a hp product. Add that to the quaint word usage and my curiosity was peaked…

Actually, you can use the option -Dgatling.fork=false to workaround the problem.