-
Bug
-
Resolution: Not A Defect
-
Minor
-
Jenkins version: 2.138.3
We are using a shared library to hold some pipeline logic. Recently, we needed this logic in some other place as well, so we decided to create a Java library with the common code. In the shared library, we are using this library via @Grab (the artifact is hosted on an internal repo).
Now we encountered a weird bug in our pipeline. In our Java library, we are doing some file modification. This works perfectly on master, however does not seem to work when the code is executed on a slave node. We confirmed that the library code is always executed on master (we executed a simple ifconfig command -> always showed IP of the master).
Our pipeline code is structured like this:
...
foo() // Executed on master
node ('node-name') {
bar() // Executed on node
libraryCall() // Executed on master
baz() // Executed on node
}
...
This is obviously very problematic and we did not find a solution for this kind of behaviour.
[JENKINS-54646] External jars in shared libraries are always executed on master
Kishore Kumar
added a comment - Tried this and this approve doesn't seem to work. Is there any specific setup that need to done prior to trying this approach.
Kishore Kumar
added a comment - Tried this and this approve doesn't seem to work. Is there any specific setup that need to done prior to trying this approach. Writefile needs both parameters as named. Try:
writeFile(file:"foo.groovy", text: libraryResource("bar.groovy")) sh "groovy foo.groovy"
Worked for me
Akseli Arvaja
added a comment - - edited
Writefile needs both parameters as named. Try:
writeFile(file: "foo.groovy" , text: libraryResource( "bar.groovy" ))
sh "groovy foo.groovy"
Worked for me This seems to be not only affecting shared libraries, but any groovy code. For example using File class in "script" block and checking if file exists does not work.
Can we have a warning when executing which may be sensitive to this? Or could this be better documented? I've spent some time debugging why my script does not work although obviously it should work 
This limits usefulnes of using groovy/shared libraries a lot
Piotr Krukowiecki
added a comment - - edited This seems to be not only affecting shared libraries, but any groovy code. For example using File class in "script" block and checking if file exists does not work.
Can we have a warning when executing which may be sensitive to this? Or could this be better documented? I've spent some time debugging why my script does not work although obviously it should work
This limits usefulnes of using groovy/shared libraries a lot
Yes, this is as designed - Pipeline Groovy execution is all within the master JVM. Steps like sh run within a node block do things like run a process on the indicated node, but the Groovy execution is still on the master. If you want to run Groovy code on the agent, you'd be best off doing something like the below, with your Groovy script in the shared library at resources/foo.groovy (rather than vars/foo.groovy):
node { writeFile(file: "script.groovy", libraryResource("foo.groovy")) sh "groovy script.groovy" }