Jenkins中用withCredentials取得设定的TOKEN，

在我们pipeline中，需要用到用户名和密码，但是，我们不想明文的的标记出用户名和密码，那就用到了Jenkins的认证管理

如下图：

 

但是在pipeline中如何使用的，可以通过下面的连接去使用

	Allows various kinds of credentials (secrets) to be used in idiosyncratic ways.
	(Some steps explicitly ask for credentials of a particular kind,
	usually as a credentialsId parameter,
	in which case this step is unnecessary.)
	Each binding will define an environment variable active within the scope of the step.
	You can then use them directly from any other steps that expect environment variables to be set:
	node {
	withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {
	sh '''
	set +x
	curl -u "$USERPASS" https://private.server/ > output
	'''
	}
	}
	As another example (use Snippet Generator to see all options):
	node {
	withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
	sh '''
	set +x
	curl -H "Token: $TOKEN" https://some.api/
	'''
	}
	}
	Note the use of single quotes to define the script
	(implicit parameter to sh) in Groovy above.
	You want the secret to be expanded by the shell as an environment variable.
	The following idiom is potentially less secure, as the secret is interpolated by Groovy
	and so (for example) typical operating system process listings will accidentally disclose it:
	node {
	withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
	sh /* WRONG! */ """
	set +x
	curl -H 'Token: $TOKEN' https://some.api/
	"""
	}
	}
	At least on Linux, environment variables can be obtained by other processes running in the same account,
	so you should not run a job which uses secrets on the same node as a job controlled by untrusted parties.
	In any event, you should always prefer expansion as environment variables to inclusion in the command,
	since Jenkins visualizations such as Blue Ocean will attempt to detect step parameters containing secrets
	and refuse to display them.
	The secret(s) will be masked (****) in case they are printed to the build log.
	This prevents you from accidentally disclosing passwords and the like via the log.
	(Bourne shell set +x, or Windows batch @echo off,
	blocks secrets from being displayed in echoed commands;
	but build tools in debug mode might dump all environment variables to standard output/error,
	or poorly designed network clients might display authentication, etc.)
	The masking could of course be trivially circumvented;
	anyone permitted to configure a job or define Pipeline steps
	is assumed to be trusted to use any credentials in scope however they like.
	For bindings which store a secret file, beware that
	node {
	dir('subdir') {
	withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
	sh 'use $FILE'
	}
	}
	}
	is not safe, as $FILE might be inside the workspace (in subdir@tmp/secretFiles/),
	and thus visible to anyone able to browse the job’s workspace.
	If you need to run steps in a different directory than the usual workspace, you should instead use
	node {
	withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
	dir('subdir') {
	sh 'use $FILE'
	}
	}
	}
	to ensure that the secrets are outside the workspace; or choose a different workspace entirely:
	node {
	ws {
	withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
	sh 'use $FILE'
	}
	}
	}

 

https://github.com/jenkinsci/credentials-binding-plugin/blob/1c2ca93a80e47f1662b160b809d4bf8876a58995/src/main/resources/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep/help.html