Hello,
I am having trouble to see the Gatling Performance trend in Jenkins using the Gatling plugin.
Here is what I use/do:
- use Gatling 2.0.0.M2
- created a simulation named stresstest
- use Jenkins Plugin 1.0.3
- My job is running OK and in the console I see:
Reports generated in 1s.
Please open the following file : /path/to/jenkins/workspace/jobname/results/stresstest-20130614163233/index.html
Archiving Gatling reports…
No newer Gatling reports to archive.
Finished: SUCCESS
And then, when I click on the little gatling icon in my job, nothing is displayed.
I have the feeling that the message “No newer Gatling reports to archive” means that there is a problem somewhere.
What I don’t get is that there actually was a report that was generated… so why the plugin does not see it?
Another thing I don’t get is this paragraph from https://github.com/excilys/gatling/wiki/Jenkins-Plugin
“As long as you are able to configure a job that will launch Gatling,
execute a simulation and generate a report in your job’s workspace
using the Maven plugin, SBT, a shell script or whatever), you’re good to go !”
=> I don’t get the last part. Why should I generate a report with one of the tool?
Reports are already generated by gatling.
I am probably missing something that is right in front my eyes…
Someone to help me?
Thanks,
Laurent
Hi,
I think I could have formulated it a bit better…
It’s always Gatling that generate the reports, but what can vary is the way you lanch Gatling.
We provide the Maven plugin, but nothing prevents you to launch Gatling with whatever tool you like. I’ll fix that part of the doc, to make it less prone to confusion.
Cheers,
Pierre
ok, thanks.
Do you have any insight for the first question of my post?
does this output from the plugin means that there is a problem and explain why I don’t see any graph?
And if so, should I store the reports somewhere than in the default folder (/results)?
Thx,
Laurent
This is the code that it uses when looking for reports:
https://github.com/jenkinsci/gatling-plugin/blob/master/src/main/java/com/excilys/ebi/gatling/jenkins/GatlingPublisher.java#L92
It should find any reports that are anywhere under the jenkins workspace folder for your job, as long as they contain a “global_stats.json” file.
It does also attempt to filter out reports that didn’t come from the most recent run; it does this by comparing the timestamp of the start time of the run against the timestamp of the report directory:
https://github.com/jenkinsci/gatling-plugin/blob/master/src/main/java/com/excilys/ebi/gatling/jenkins/GatlingPublisher.java#L141
If you are seeing the “No newer Gatling reports to archive” message, then one of the two things above probably didn’t match.
Thanks for your answer.
I am still fighting to make it work without success.
Like you mention, it seems that the plugin needs a global_stats.json file,
but I never have such a file in my result folder.
Here is what I usually find in a given result sub-folder (I tried on Centos and MacOSx):
(see bellow)
Is there anything to configure to get this global_stats.json ?
Thanks,
Laurent
[MBP-lo]$ ll
total 952
-rw-r–r-- 1 laurent staff 23333 25 jui 17:04 index.html
drwxr-xr-x 13 laurent staff 442 25 jui 17:04 js
-rw-r–r-- 1 laurent staff 18410 25 jui 17:04 req_config-sso-dd8904a13c001dee45fe97f36323cf28.html
-rw-r–r-- 1 laurent staff 18647 25 jui 17:04 req_get-ad-account-d5f7026637be29ee76275b9d1d3e24ba.html
-rw-r–r-- 1 laurent staff 18174 25 jui 17:04 req_info-login-fails-3cb81fa0fa69f5461a569fe4c876634b.html
-rw-r–r-- 1 laurent staff 18267 25 jui 17:04 req_login-success-660dda700fbf285c12d4f40b4ab59dad.html
-rw-r–r-- 1 laurent staff 19207 25 jui 17:04 req_request-1-46da482b5ba7614b7124accf72d8b1ce.html
-rw-r–r-- 1 laurent staff 18160 25 jui 17:04 req_request-11-f11e8d55a16ce73fd22512921519d65e.html
-rw-r–r-- 1 laurent staff 18064 25 jui 17:04 req_request-14-a0e301b97cf38dbd3cfb0725f67f43d3.html
-rw-r–r-- 1 laurent staff 18153 25 jui 17:04 req_request-15-56eaca142dfddbabc237f29e67ec884a.html
-rw-r–r-- 1 laurent staff 18153 25 jui 17:04 req_request-16-247335d046d816105b9ebdadc5b3be5c.html
-rw-r–r-- 1 laurent staff 18158 25 jui 17:04 req_request-17-cd6a292504f8223766e6d943b40fcdfd.html
-rw-r–r-- 1 laurent staff 18232 25 jui 17:04 req_request-2-93baff648d9a0c13a48ee1d38e7b220f.html
-rw-r–r-- 1 laurent staff 18315 25 jui 17:04 req_request-3-d09735bb02d6e5012b92b4f819ff64cc.html
-rw-r–r-- 1 laurent staff 18335 25 jui 17:04 req_request-4-e7d1b1bd5d422b9c4051b94ac981cc91.html
-rw-r–r-- 1 laurent staff 18205 25 jui 17:04 req_request-5-48829dc27f9f565bbe1021ea0e005040.html
-rw-r–r-- 1 laurent staff 18334 25 jui 17:04 req_request-6-027a986b276e85edb9fc05dfa564c868.html
-rw-r–r-- 1 laurent staff 18200 25 jui 17:04 req_request-7-f222f67b6eaeefa6fd794f5864b52d5a.html
-rw-r–r-- 1 laurent staff 18207 25 jui 17:04 req_request-8-ef0c844bd0bb2bd86cddee05b47dc1ed.html
-rw-r–r-- 1 laurent staff 18202 25 jui 17:04 req_request-9-d127ea1ed17ba130bfaea83427418f34.html
-rw-r–r-- 1 laurent staff 18350 25 jui 17:04 req_saml-assertion-generator-991d437b0c3ba97f06628d8d1576d114.html
-rw-r–r-- 1 laurent staff 18479 25 jui 17:04 req_test-ad-2d0fe1c99ef5d66a7b565a0622f0277c.html
-rw-r–r-- 1 laurent staff 19209 25 jui 17:04 req_ui-configuration-50686432f967c2dfb14115c5fe2e8b4a.html
-rw-r–r-- 1 laurent staff 26242 25 jui 17:04 simulation.log
-rw-r–r-- 1 laurent staff 3828 25 jui 17:04 stats.tsv
drwxr-xr-x 22 laurent staff 748 25 jui 17:04 style
It’s in the js directory.
oh my… sorry…
this leaves me with the second possible issue :
“It does also attempt to filter out reports that didn’t come from the most recent run; it does this by comparing the timestamp of the start time of the run against the timestamp of the report directory:”
So it is maybe a timestamp issue between my jenkins master and the slave where the jobs run.
So I just checked “clock difference” in Jenkins/admin/nodes and I see there is a “-2mn” difference
Maybe the problem comes from here… the plugin thinks the new folder is old (2mn) whereas it is new…
(if (reportLastMod > buildStartTime) is false)
I guess I will try to fix my clock issue then…
Thanks!
Laurent
Interesting. There might be a way to handle that in the code, hadn’t thought about it. Would definitely be curious to here whether or not syncing the clocks fixes the problem for you!
It does fix my problem.
Having all the nodes in clock-sync is something I should have done anyway.
Could be nice to handle that in the plugin although I don’t know how to do it.
Laurent
Well, at least we know where to look.
Thanks for your feedback, Laurent. I hope you’ll enjoy the plugin.
Cheers,
Stéphane