println in "call()" in "vars/xx.groovy" shows in console, but println in defed method in class in "vars/xx.groovy" is just ignored

789 views
Skip to first unread message

David Karr

unread,
Feb 11, 2017, 12:49:42 AM2/11/17
to Jenkins Users
I'm seeing some odd behavior with "println" calls in shared library methods, and a perhaps related issue with printing a shared library object in a Jenkinsfile.

I've been using https://jenkins.io/doc/book/pipeline/shared-libraries/ as my implementation guide.

I've been working on evolving a shared library.  I started with a Jenkinsfile with several methods that I've been copying to a handful of other Jenkinsfiles, so I decided it was time to remove duplication and move them to a shared library.  I first created a "vars/foo.groovy" with a "call()" method, with the body of my original "foo" method from the Jenkinsfile.  This worked fine, and I note that "println" calls within the "call" method resulted in that string in the Jenkins job console.

However, I found that the negative part of moving those methods to "vars" files was that I now had to pass several global variables ("params.." and "env..") as parameters to those methods (actually, I don't know for certain that I actually had to do that, but I don't think I would want to depend on that working).

So, I decided to try defining a class in a "vars" file, with several instance variables for for those "params." and "env." variables, and "def" methods for each of the methods that I used to have in standalone "vars" files.  So far, I've tested this a little bit, and functionally this appears to work.  However, what's very odd is that if I have a "println" call within one of the "def"ed methods in the class, when it's executed during the job, it's like it just skips over it.  The output from that line just doesn't appear in the console.

I also noticed another seemingly related behavior that might be something completely different.  The file I had created to store the class was "vars/uslutils.groovy" (with "class uslutils implements Serializable" in the file). I also implemented a "public String toString()" method in the defined class, which just returns a string containing all the instance variables in a gstring. In my Jenkinsfile, I referenced "uslutils.varname" and "uslutils.methodname", and that worked fine.  However, I also had a println call in the Jenkinsfile itself that just printed "uslutils[${uslutils}]".  Right after that line, I had another println call for "uslutils[${uslutils.toString()}]".  The output from the latter line appeared in the console.  The output from the former line did not appear.

Ilguiz Latypov

unread,
Apr 14, 2018, 5:35:45 AM4/14/18
to Jenkins Users


On Saturday, 11 February 2017 00:49:42 UTC-5, David Karr wrote:
I'm seeing some odd behavior with "println" calls in shared library methods, and a perhaps related issue with printing a shared library object in a Jenkinsfile.

Nice to see an answer to this by Jon S a month later where he suggested to pass the "this" reference to the "src" class instance (apparently it has an interface Script).  Calling script.echo("...") in a method of that instance will work.  (Without binding to the script object, my bare "echo" in an "src" instance method resulted in a silent termination of the step).

Jon S also suggested to add a @NonCPS annotation to the "src" instance methods and declare the "src" class Serializable to allow executing the method from the context of a slave node.


Reply all
Reply to author
Forward
0 new messages