Credentials Binding

Allows credentials to be bound to environment variables for use from miscellaneous build steps.

You may have a keystore for jarsigner, a list of passwords, or other confidential files or strings which you want to be used by a job but which should not be kept in its SCM, or even visible from its config.xml. Saving these files on the server and referring to them by absolute path requires you to have a server login, and does not work on agents. This plugin gives you an easy way to package up all a job’s secret files and passwords and access them using a single environment variable during the build.

To use, first go to the Credentials link and add items of type Secret file and/or Secret text. Now in a freestyle job, check the box Use secret text(s) or file(s) and add some variable bindings which will use your credentials. The resulting environment variables can be accessed from shell script build steps and so on. (You probably want to start any shell script with set +x, or batch script with @echo off. JENKINS-14731).

For more details of how this works, check the Injecting secrets into builds article at CloudBees.

From a Pipeline job, define your credentials, then check Snippet Generator for a syntax example of the withCredentials step. Any secrets in the build log will be masked automatically.

A typical example of a username password type credential (example from here) would look like: 

withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
  // available as an env variable, but will be masked if you try to print it out any which way
  // note: single quotes prevent Groovy interpolation; expansion is by Bourne Shell, which is what you want
  sh 'echo $PASSWORD'
  // also available as a Groovy variable
  echo USERNAME
  // or inside double quotes for string interpolation
  echo "username is $USERNAME"
}

You should use a single quote (') instead of a double quote (") whenever you can. This is particularly important in Pipelines where a statement may be interpreted by both the Pipeline engine and an external interpreter, such as a Unix shell (sh) or Windows Command (bat) or Powershell (ps). This reduces complications with password masking and command processing. The first step in the above example properly demonstrates this. It references an environment variable, so the single-quoted string passes its value unprocessed to the sh step, and the shell interprets $PASSWORD. The next two steps use the basic Pipeline echo step. The last one needs to use double quotes, so that the string interpolation is performed by the Pipeline DSL.

For more information, see the Pipeline step reference for Credentials Binding Plugin.

See GitHub Releases for new releases (version 1.20 and newer), or the old changelog for history (version 1.19 and earlier).