[JIRA] (JENKINS-54646) External jars in shared libraries are always executed on master

[simon.schiller@runtastic.com (JIRA)]

Simon Schiller created an issue

Jenkins / JENKINS-54646 External jars in shared libraries are always executed on master Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2018-11-15 12:27 Environment: Jenkins version: 2.138.3 Labels: pipeline shared-libraries Priority: Minor Reporter: Simon Schiller 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. Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[andrew.bayer@gmail.com (JIRA)]

Andrew Bayer resolved as Not A Defect

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" }

Jenkins / JENKINS-54646 External jars in shared libraries are always executed on master

Change By: Andrew Bayer Status: Open Resolved Resolution: Not A Defect

Add Comment

[kishorekumarbg@gmail.com (JIRA)]

Kishore Kumar commented on JENKINS-54646

Re: External jars in shared libraries are always executed on master Tried this and this approve doesn't seem to work. Is there any specific setup that need to done prior to trying this approach.

Add Comment

[akseli.arvaja@gmail.com (JIRA)]

Akseli Arvaja commented on JENKINS-54646

Re: External jars in shared libraries are always executed on master

Writefile needs both parameters as named. Try:    {{writeFile(file:"foo.groovy", text: libraryResource("bar.groovy"))}} {{sh "groovy foo.groovy"}}  Worked for me {{}}

Add Comment

[akseli.arvaja@gmail.com (JIRA)]

Akseli Arvaja edited a comment on JENKINS-54646

[akseli.arvaja@gmail.com (JIRA)]

Akseli Arvaja edited a comment on JENKINS-54646

Re: External jars in shared libraries are always executed on master

Writefile needs both parameters as named. Try:

{ { code} writeFile(file:"foo.groovy", text: libraryResource("bar.groovy")) }} {{ sh "groovy foo.groovy" {code } }  Worked for me \{{}}

Add Comment

[pkruk@parasoft.com (JIRA)]

Piotr Krukowiecki commented on JENKINS-54646

Re: External jars in shared libraries are always executed on master

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 shared libraries a lot

Add Comment

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)

[pkruk@parasoft.com (JIRA)]

Piotr Krukowiecki edited a comment on JENKINS-54646

Re: External jars in shared libraries are always executed on master

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 :(

Add Comment