Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-40650

If "withCredentials" and "UsernamePasswordMultiBinding" doesn't specify BOTH a username and password variable,it corrupts other variables

XMLWordPrintable

      I have a block of code like this in my pipeline script:

      						withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: JP_MechIdCredentials, usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
      							println "JP_MechIdPrivateKey[${JP_MechIdPrivateKey}]"
      							sshagent (credentials: [JP_MechIdPrivateKey]) {
      								sh "scp -o StrictHostKeyChecking=no ${javadocJarPath} ${USERNAME}@${JP_JavadocJarHost}:/tmp"
      								sh "ssh -o StrictHostKeyChecking=no ${USERNAME}@${JP_JavadocJarHost} \"cd  ${JP_JavadocRootRemotePath}; rm -rf ${versionNumber}; mkdir ${versionNumber}\""
      								sh "ssh -o StrictHostKeyChecking=no ${USERNAME}@${JP_JavadocJarHost} \"cd ${JP_JavadocRootRemotePath}/${versionNumber}; jar xvf /tmp/${baseFileName}\""
      							}
      						}
      

      Note that I reference the USERNAME, but not the PASSWORD. So, I thought it would be cleaner if I simply removed ", passwordVariable: 'PASSWORD'".

      This didn't work, and it produced very strange results. The error I got was the following:

      groovy.lang.MissingPropertyException: No such property: JP_MechIdPrivateKey for class: groovy.lang.Binding
      

      Note that this is the variable referenced on the line after this, in the "println". The stacktrace shows it occurring on that line.

      If I add the password variable binding back, it works fine. This is seriously weird.

      Despite the brokenness of this, you might ask "if you're not getting the password, why don't you just change it to a string parameter?" I actually like the ability to select the credential from the menu in the job parameters. Changing it to a string would require me to just hardcode the principal name.

      I had someone else test a similar script on another Jenkins instance, and they got effectively the same result. It seemed to corrupt the variable referenced on the line after the "withCredentials" block started.

            Unassigned Unassigned
            dkarr David Karr
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: