Summary

Certain legitimate groovy expressions, when present in a groovy global shared library will cause any pipeline job that attempts to load the library to hang at the point immediately after the library is loaded. This occurs with no errors in the job console nor any errors in the jenkins logs, effectively leaving the user to have to start guessing at possible causes.

Steps to Reproduce

I don't know if there are other scenarios that will cause this but here is a reproducible one that I have come up with.

Step 1

Create a repo in git and configure it to be loaded on demand. In our case we are loading under the name 'pipeline-utils'.

Step 2

Create the following file in that library:

/src/examples/Bug.groovy

with conntent:

package examples
import groovy.transform.Field

// This is the line that seems to be the real cause of the problem.  A final static field that invokes a function to get its value.
@Field def static final API_BASE_URL = absolutizeUrl("api")

def static absolutizeUrl(relativeUrl) { return "http://myserver/${relativeUrl}" }

Step 3

Now create a pipeline job with the following DSL:

@Library('pipeline-utils')
import examples.Bug

//Though the bug seems to be triggered by the field declaration, it isn't activated if we don't invoke a function from the class in question.
println Bug.absolutizeUrl('ui')

Step 4

Run this job and you will get output similar to the following:

Started by user Baltrinic, Kenneth
Loading library pipeline-utils@master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://git@stash:7999/jenkins/pipeline-utils.git # timeout=10
Fetching upstream changes from ssh://git@stash:7999/jenkins/pipeline-utils.git
 > git --version # timeout=10
 > git fetch --tags --progress ssh://git@stash:7999/jenkins/pipeline-utils.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 164a989ac7555e33541894d966075819c3e66143 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 164a989ac7555e33541894d966075819c3e66143
 > git rev-list 395d5408a41619030e2855f01bb55a7103ce6b10 # timeout=10

At this point there will be no further console output and the job is hung and must be forcibly aborted.

Recommendations

This is admittedly an esoteric scenario. I am not so concerned that a fix be implemented to allow this code to load correctly. My main concern is that the failure must not be silent. It may be impossible to account for all the ways in which things might fail to load or be processed by the CPS system, etc. But better error reporting that clearly identifies the offending file and line number should be possible. This took me the better part of five hours to run down given the dearth of info I had to go on and the size of the code base I was dealing with.