# credentials-binding-plugin

**Repository Path**: mamh-java/credentials-binding-plugin

## Basic Information

- **Project Name**: credentials-binding-plugin
- **Description**: https://github.com/mamh-java/credentials-binding-plugin
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-05-14
- **Last Updated**: 2025-03-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Jenkins Credentials Binding Plugin
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](https://issues.jenkins-ci.org/browse/JENKINS-14731)).

For more details of how this works, check the [Injecting secrets into builds](https://docs.cloudbees.com/docs/cloudbees-ci/latest/cloud-secure-guide/injecting-secrets)
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: 

```groovy
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"
}
```

#### Note

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](https://en.wikipedia.org/wiki/String_interpolation) is performed by the Pipeline DSL.

For more information, see the Pipeline step reference for [Credentials Binding Plugin](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/).

## Changelog

See [GitHub Releases](https://github.com/jenkinsci/credentials-binding-plugin/releases) for new releases (version 1.20 and newer),
or the [old changelog](old-changelog.md) for history (version 1.19 and earlier).