Oh right, but the good thing is that it gave us even more information!
My Jenkins configuration is as follow
Master node runs with the a “MasterUser” (which is not a sudoer)
The slave node I used for this last test is running on the same machine, but with another user, lets say the “SlaveUser” (which is a sudoer, but I guess it doesn’t matter much).
So this exception tells us that the Gatling plugin tried to retrieve the log file with the MasterUser, which doesn’t have access to the SlaveUser’s workspace… or the slave altogether when the slave is on another computer.
I’ve been using Jenkins heavily for a few years but I have never developped a plugin, so I don’t know much about plugin coding, so I might be totally wrong, but that sure looks like that.
If it could be useful for you, I guess I could confirm this by adding a nice “chmod 777” during the build.
I agree, I think your issues with both Windows & Linux slaves reduces to a simple permissions problem.
I’m not an expert on Windows & permissions, but I suppose that, in case of missing permissions, Linux explicitly indicates that the user has not permissions to access the file and for Windows, the user just can’t see the file, and so it’s behind an “missing file or directory” error.
I checked the Gatling Jenkins plugin code, and we use a Jenkins’ abstraction for files, FilePath, which allow transparent access to files whether they are on a master or slave node, so the plugin should have no problem to retrieve the file on your slave node.
It would be great if you can try chmod-ing during the build, to see if we’re both on the right track
It would be great if you can try chmod-ing during the build, to see if we’re both on the right track
I tried chmod-ing, and in the case “slave and master on same computer”, it works.
I agree, I think your issues with both Windows & Linux slaves reduces to a simple permissions problem.
I’m not sure it’s that simple.
In the case where both slave and master are on same computer, allowing the master-user to have access to the slave-folders does workaround the issue.
But if the plugin is indeed using the master-user instead of the slave-user, I don’t think it could be a durable fix.
First because it won’t work if slave and master are not on the same computer ;
Second because it’s pretty damn ugly!
Once again, I know pretty darn nothing about Jenkins plugin development, but I guess there should be a way of bringing back the file from slave to master using the slave user ; a few plugins does that without issue, such as Document Publisher plugin.
I agree, that’s a dirty hack to make it work and also, a terrible setup : can’t expect anything much in terms of performance from a setup where both the master and the the slave are on the same computer…
Thank you for pointing out that HTML Publisher does it without issues, I took a quick look at their code and found something they do during file copying that we don’t… maybe be a trail to solve your problem.
I’ll get back to you when I have more info.
Sorry for the delay, it’s quite a mess to setup a distributed Jenkins…but I was able to reproduce your bug.
Can you please send me the full stacktrace of the exception you got ?
You sent the stacktrace for the first exception you got, but it was caused by the error in your output directory prefix.
No problem for the delay, there is no hurry.
And yes, Windows Jenkins-slaves are a nightmare to properly setup. =D (I often use the jnpl agent and just put it into the windows Startup folder… )
I’ll send you the full stacktrace tomorrow morning, I can’t access my Jenkins at work from home.
Hum,
nevermind, I re-run the job and now the report appears correctly.
I have no idea what went wrong…
I’ll keep you posted if I manage to reproduce the issue.
One tiny little bothering thing :
all the titles of the gatling pages are “Main layout”.
It’s not really usefull when you have several gatling pages opened.
( And yes, the fact that I’m down to these critics is a really good thing. =D )
