CODEWITHSUNDEEP
jenkinsjenkins-pipeline
user2511126
user2511126

Reputation: 650

Jenkins pipeline lock is not getting released

I am getting this null pointer exception and the lock is not getting freed, it was working correctly for a long and suddenly started to throw this exceptions

any one has any idea?

stage('Deploy to iDev') {       
    steps {
        script {
            lock(resource: "$DEV_LOCK", inversePrecedence: true) {
                milestone (15)
                ansiColor('xterm') {
                    ansibleTower credential: '',
                    extraVars: "$DEV_ANSIBLE_PARAMS",
                    importTowerLogs: true,
                        importWorkflowChildLogs: false,
                        inventory: '',
                        jobTags: '',
                        jobTemplate: "$DEV_ANSIBLE_ID",
                        jobType: 'run',
                        limit: '',
                        removeColor: false,
                        skipJobTags: '',
                        templateType: 'job',
                        towerServer: "$TOWER_SERVER",
                        verbose: true
                }
            }

            if ("$DEV_CONTAINER_JOB" != 'NA') {
                build job: "$DEV_CONTAINER_JOB"
            }
            if ("$DEV_TEST_JOB" != 'NA') {
                build job: DEV_TEST_JOB, parameters: [[$class: DEV_TEST_PARAMS_CLASS, name: DEV_TEST_PARAMS_NAME, value:  DEV_TEST_PARAMS_VALUE]]
            }
        }
    }
    post {
        failure {
            // We want to email the development team.           
        }
        aborted {
            echo "aborted.. during deploy to iDev"
        }
    }
}

errors are below:

java.lang.NullPointerException
    at org.jenkins.plugins.lockableresources.LockableResourcesManager.freeResources(LockableResourcesManager.java:323)
    at org.jenkins.plugins.lockableresources.LockableResourcesManager.unlockNames(LockableResourcesManager.java:367)
    at org.jenkins.plugins.lockableresources.LockStepExecution$Callback.finished(LockStepExecution.java:125)
    at org.jenkinsci.plugins.workflow.steps.BodyExecutionCallback$TailCall.onSuccess(BodyExecutionCallback.java:114)
    at org.jenkinsci.plugins.workflow.cps.CpsBodyExecution$SuccessAdapter.receive(CpsBodyExecution.java:368)
    at com.cloudbees.groovy.cps.Outcome.resumeFrom(Outcome.java:73)

Upvotes: 2

Views: 4076

Answers (2)

Carlos Robles
Carlos Robles

Reputation: 10947

As a first look, I would say that $DEV_LOCK doesn't exist at the moment it is evaluated. Just for the sake of argument, you can try to change it for a static string temporary, let's say

lock(resource: "foo", inversePrecedence: true)

Getting a bit deeper into it, and

  • seeing this line of the error stack trace org.jenkins.plugins.lockableresources.LockableResourcesManager.freeResources(LockableResourcesManager.java:323)

  • judging by the date of this post,

  • and the commit history of the plugin...

...I would say that we are talking about this line in the plugin's code: https://github.com/jenkinsci/lockable-resources-plugin/blob/79034dcd1c12f88030b0990356ad9f7c63d1937e/src/main/java/org/jenkins/plugins/lockableresources/LockableResourcesManager.java#L323

The line is 

323. private synchronized void freeResources(List<String> unlockResourceNames, @Nullable Run<?, ?> build) {
321.  for (String unlockResourceName : unlockResourceNames) {
322.            for (LockableResource resource : this.resources) {
323.                if (resource != null && resource.getName() != null && resource.getName().equals(unlockResourceName)) {

we can see that resource is not null, and resource.getName() is not null, so the only possible null thing there is unlockResourceName, which makes sense since it is not checked in the lines above.

So it looks like the resource name of your resource (remember that your resource was $DEV_LOCK) happens to be null.

so I would say that the test proposed above, using just lock(resource: "foo", inversePrecedence: true) to see if the problems come from there, would be a good starting point. If it works, then you can decide if you really need $DEV_LOCK as a env variable, or you can change it for something static. If you needed it then take it from there trying to find out where it is unset, or if it is actually set somewhere.

Upvotes: 0

KeepCalmAndCarryOn
KeepCalmAndCarryOn

Reputation: 9075

As per this

you need to do this as the lock is a declarative step or wrapper

stage('Deploy to iDev') {
    steps {
        lock(resource: "$DEV_LOCK", inversePrecedence: true) {
            script {
               .
                .
                .
            }
        }
    }
}

You might run into problems with $DEV_LOCK too, depending how you defined it. You might be able to do "${env.DEV_LOCK}" or "${DEV_LOCK}"

Looking a bit closer, I think you only need to script the if statements. You could even put build job... into separate stages using when clauses with expressions and lose the script altogether and lock the whole pipeline as per my first link answer

Upvotes: 2

Related Questions