[JIRA] [credentials-binding-plugin] (JENKINS-32402) Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs

206 views
Skip to first unread message

nirvine@bns-g.com (JIRA)

unread,
Jan 11, 2016, 8:04:01 PM1/11/16
to jenkinsc...@googlegroups.com
Nick Irvine created an issue
 
Jenkins / Bug JENKINS-32402
Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs
Issue Type: Bug Bug
Assignee: Jesse Glick
Attachments: creds-config.xml
Components: credentials-binding-plugin
Created: 12/Jan/16 1:03 AM
Priority: Major Major
Reporter: Nick Irvine

This job attempts to:

  • Take a parameter GAMESPARKS_CREDS_ID as creds
  • Use Credentials Binding to convert the creds into an environment variable GAMESPARKS_CREDS that is the concatenation of username:password for use in a shell script
  • Do so every 2 minutes

When triggered manually, it works fine. But when triggered by the timer, it fails with the following message:

FATAL: ${GAMESPARKS_CREDS_ID}
org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: ${GAMESPARKS_CREDS_ID}
	at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:124)
	at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordBinding.bindSingle(UsernamePasswordBinding.java:50)
	at org.jenkinsci.plugins.credentialsbinding.Binding.bind(Binding.java:126)
	at org.jenkinsci.plugins.credentialsbinding.impl.SecretBuildWrapper.setUp(SecretBuildWrapper.java:58)
	at hudson.model.Build$BuildExecution.doRun(Build.java:156)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:537)
	at hudson.model.Run.execute(Run.java:1744)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:374)
Finished: FAILURE

If there's a better way to make credentials available in a build script, I'm open to that.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

jerod.sikorskyj@gmail.com (JIRA)

unread,
Jan 12, 2016, 8:46:01 PM1/12/16
to jenkinsc...@googlegroups.com
Jerod Sikorskyj commented on Bug JENKINS-32402
 
Re: Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs

I can reproduce Nick's issue, and my own notice of it arose in a similar context. One workaround for timed jobs which need a parameterized expression, is to create a secret file in the credentials pre-build parameter, and then use the environment variable in the parameter expression in the credentials binding plugin part of the job (i.e. "my_secret_file"), then include a shell step, and source the secret file.
i.e. upload this file

___secret_evn.sh
username=luke
password=skywalker
___

And then in the shell step, "source $

{my_secret_file}

jerod.sikorskyj@gmail.com (JIRA)

unread,
Jan 12, 2016, 8:47:01 PM1/12/16
to jenkinsc...@googlegroups.com
Jerod Sikorskyj edited a comment on Bug JENKINS-32402

jerod.sikorskyj@gmail.com (JIRA)

unread,
Jan 12, 2016, 8:47:01 PM1/12/16
to jenkinsc...@googlegroups.com

jerod.sikorskyj@gmail.com (JIRA)

unread,
Jan 12, 2016, 9:28:02 PM1/12/16
to jenkinsc...@googlegroups.com
Jerod Sikorskyj edited a comment on Bug JENKINS-32402
I can reproduce Nick's issue, and my own notice of it arose in a similar context.  One workaround for timed jobs which need a parameterized expression, is to create a secret file in the credentials pre-build parameter, and then use the environment variable in the parameter expression in the credentials binding plugin part of the job (i.e. "my_secret_file"), then include a shell step, and source the secret file.
i.e. upload this file

___secret_evn.sh
#!/bin/bash
export username=luke
 export password=skywalker

___

And then in the shell step, source ${my_secret_file}

jerod.sikorskyj@gmail.com (JIRA)

unread,
Jan 12, 2016, 9:52:02 PM1/12/16
to jenkinsc...@googlegroups.com
Jerod Sikorskyj edited a comment on Bug JENKINS-32402
I can reproduce Nick's issue, and my own notice of it arose in a similar context .  One workaround for timed jobs which need a parameterized expression, is to create a secret file in the credentials pre-build parameter, and then use the environment variable in the parameter expression in the credentials binding plugin part of the job (i.e. "my_secret_file"), then include a shell step, and source the secret file.

i.e. upload this file

___secret_evn.sh
#!/bin/bash
export username=luke
export password=skywalker
___

And then in the shell step, source ${my_secret_file}

nikolay.v.borisenko@gmail.com (JIRA)

unread,
Feb 2, 2016, 1:38:01 PM2/2/16
to jenkinsc...@googlegroups.com

I am using "Role Strategy" plugin. The issue is not reproducible only if "Anonymous" has access to configure jobs.

maskmaster (JIRA)

unread,
Jun 7, 2016, 6:14:01 AM6/7/16
to jenkinsc...@googlegroups.com

I am using the promotions plugin to deploy a build to different servers.
I have a timed build that auto-deploys to a specific server using secret file credentials. (global credentials)
If I want to manually promote the same build to another server I get the credentials exceptions described here.
However, if I do a manual build of the same revision, the manual promotion works as expected.

jglick@cloudbees.com (JIRA)

unread,
Nov 7, 2016, 5:04:02 PM11/7/16
to jenkinsc...@googlegroups.com

Possibly a duplicate of JENKINS-35490?
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

andre.mt.bierlein@gmail.com (JIRA)

unread,
Nov 28, 2016, 10:41:01 AM11/28/16
to jenkinsc...@googlegroups.com

I am currently running into what I believe to be the same issue as Martin S.. I have a job that is triggered by git push, which has a few promotions for different environments. The promotions all trigger the same deployment job with different values for the credential parameter. When I run the promotion I get the CredentialNotFoundException, while triggering the deployment manually works perfectly fine. When comparing the two builds (manual vs promoted) they look absolutely identical, both showing the credentials that I provided as well as the respective environment variable.
It's not obvious to me how exactly these invocations differ from each other, so I don't know if this is a bug or a configuration mistake on my side.

aubert.aa@gmail.com (JIRA)

unread,
Jan 25, 2017, 3:01:04 AM1/25/17
to jenkinsc...@googlegroups.com

Hi,

I'm facing the same issue, here is the description :

I have a multibranch pipeline that triggered another job with parameters, here is the trigger block :

~ build job: 'Archis/front-s3-deployer',
parameters: [
string(name: 'SourcePackagePath', value: "Internal/DataViz/Vega/$

{env.BRANCH_NAME}

/Binary/$

{env.BUILD_NUMBER}

/"),
string(name: 'SourcePackageName', value: 'vega.zip'),
string(name: 'DestinationBucket', value: 'datavizclouddev.net'),
string(name: 'DestinationPath', value: 'vega/'),
[$class: 'CredentialsParameterValue', description: 'Credentials used to write on the destination bucket', name: 'StoredAccessKeyName', value: 'aws-dataviz']
]~

If i launch this job manually, parameters are well passed to second job and second job builds ok :

^Started by upstream project "DataViz/VegaWebApp/Vega-Deploy/dev" build number 159
originally caused by:
Started by user Alexandre
[EnvInject] - Loading node environment variables.
Building remotely on Archis - awsbld001 (Archis BDXBLD013 -) in workspace /home/admin/jenkins/workspace/Archis/front-s3-deployer
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
[front-s3-deployer] $ /bin/sh -xe /tmp/hudson5564189863560131079.sh
...^

If this job is trigger automatically, i can see that parameters are well passed to second job (by checking the 'parameters' page of the triggered build : all values are well populated - exactly as for the manually triggered run) but i got an error message when second job's build starts :

^Started by upstream project "DataViz/VegaWebApp/Vega-Deploy/dev" build number 160
originally caused by:
Branch indexing
[EnvInject] - Loading node environment variables.
Building remotely on Archis - awsbld001 (Archis BDXBLD013 -) in workspace /home/admin/jenkins/workspace/Archis/front-s3-deployer
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
FATAL: $

{StoredAccessKeyName}
org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: ${StoredAccessKeyName}

at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:131)
at com.cloudbees.jenkins.plugins.awscredentials.AmazonWebServicesCredentialsBinding.bind(AmazonWebServicesCredentialsBinding.java:93)
at org.jenkinsci.plugins.credentialsbinding.impl.SecretBuildWrapper.setUp(SecretBuildWrapper.java:96)
at hudson.model.Build$BuildExecution.doRun(Build.java:156)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1729)


at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)

at hudson.model.Executor.run(Executor.java:404)
Notifying upstream projects of job completion
...^

Environment :

Jenkins 2.41
Credential-bindings 1.10
Credentials Plugin 2.1.10
CloudBees Amazon Web Services Credentials Plugin 1.17

aubert.aa@gmail.com (JIRA)

unread,
Jan 25, 2017, 3:02:03 AM1/25/17
to jenkinsc...@googlegroups.com
Alexandre Aubert edited a comment on Bug JENKINS-32402
Hi,

I'm facing the same issue, here is the description :

I have a multibranch pipeline that triggered another job with parameters, here is the trigger block :

 ~                build job: 'Archis/front-s3-deployer',
                parameters: [
                    string(name: 'SourcePackagePath', value: "Internal/DataViz/Vega/${env.BRANCH_NAME}/Binary/${env.BUILD_NUMBER}/"),
                    string(name: 'SourcePackageName', value: 'vega.zip'),
                    string(name: 'DestinationBucket', value: 'datavizclouddev.net'),
                    string(name: 'DestinationPath', value: 'vega/'),
                    [$class: 'CredentialsParameterValue', description: 'Credentials used to write on the destination bucket', name: 'StoredAccessKeyName', value: 'aws-dataviz']
                ] ~

If i launch this job manually, parameters are well passed to second job and second job builds ok :
^ Started by upstream project "DataViz/VegaWebApp/Vega-Deploy/dev" build number 159
originally caused by:
*Started by user Alexandre*

[EnvInject] - Loading node environment variables.
Building remotely on Archis - awsbld001 (Archis BDXBLD013 -) in workspace /home/admin/jenkins/workspace/Archis/front-s3-deployer
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
[front-s3-deployer] $ /bin/sh -xe /tmp/hudson5564189863560131079.sh
...
^

If this job is trigger automatically, i can see that parameters are well passed to second job (by checking the 'parameters' page of the triggered build : all values are well populated - exactly as for the manually triggered run) but i got an error message when second job's build starts :

^ Started by upstream project "DataViz/VegaWebApp/Vega-Deploy/dev" build number 160
originally caused by:
*Branch indexing*
^

bpatton00@yahoo.com (JIRA)

unread,
Feb 3, 2017, 4:39:03 PM2/3/17
to jenkinsc...@googlegroups.com

I am having the same issue and to compound it when rebuilding the project it will work correctly. It appears to be a difference between Jenkins identifying the credentials and binding them and not.

bpatton00@yahoo.com (JIRA)

unread,
Feb 3, 2017, 4:39:08 PM2/3/17
to jenkinsc...@googlegroups.com
bryan patton edited a comment on Bug JENKINS-32402
I am having the same issue and to compound it when rebuilding the project task it will work correctly.  It appears to be a difference between Jenkins identifying the credentials and binding them and or not.  

jglick@cloudbees.com (JIRA)

unread,
Mar 6, 2017, 4:13:02 PM3/6/17
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Unassigned
 
Change By: Jesse Glick
Assignee: Jesse Glick
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

gucore@redhat.com (JIRA)

unread,
Mar 3, 2018, 9:44:02 AM3/3/18
to jenkinsc...@googlegroups.com
Guillaume Coré commented on Bug JENKINS-32402
 
Re: Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs

> For you information, I created new credentials and let Jenkins generating the ID instead of setting it and it worked.

Mathieu Beausoleil  i tried, creating a new credentials with generated ID does not fix the issue for me

jglick@cloudbees.com (JIRA)

unread,
Mar 19, 2018, 9:45:02 AM3/19/18
to jenkinsc...@googlegroups.com

Sounds like a user error. Credentials parameters could not be used across jobs like this. You would need to have the upstream extract the secret and then pass it downstream via a password parameter, I suppose.

Maksym.Kit@eleks.com (JIRA)

unread,
May 22, 2018, 11:14:02 AM5/22/18
to jenkinsc...@googlegroups.com

I observe the same behavior. I have a Job A, which triggers Job B and passes an credentials ID using Jenkins Parameterized Trigger Plugin Predefined parameters. Job B project is parameterized and has Credentials Parameter specified. Job B also has "Use secret text(s) or file(s)" enabled (provided with Credentials Binding Plugin) and a corresponding binding specified.

When I start Job A manually Job B will start correctly and have credentials resolved correctly, however when Job A is being triggered by GitHub push Job B will fail to resolve credentials.

Sounds like a user error. Credentials parameters could not be used across jobs like this.

Why?

info+jenkinsci@csullivan.net (JIRA)

unread,
Jan 28, 2019, 11:57:06 AM1/28/19
to jenkinsc...@googlegroups.com

I worked around this issue by using the Authorize Project plugin. Instead of passing the credentials from the upstream job, I set the defaultValue of the parameter instead to globally scoped credentials.

For build "Authorization" (enabled by Authorize Project), I set the job to run as a user with access to the global credentials (I would have used credentials scoped to the user only, but you can't use these as default values). When selecting "Build with Parameters" as any other user, only the user scoped credentials are available.

Other users can still pass parameters to the job and successfully run it if they have the correct credentials. If they try to run the job without specifying their own credentials, they can not access the default credentials and the job fails as desired.

When initiated by timer, it uses the default globally scoped credentials and successfully runs.
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

info+jenkinsci@csullivan.net (JIRA)

unread,
Jan 28, 2019, 12:12:04 PM1/28/19
to jenkinsc...@googlegroups.com
I worked around this issue by using the [Authorize Project plugin|https://wiki.jenkins.io/display/JENKINS/Authorize+Project+plugin]. Instead of passing the credentials from the upstream job, I set the {{defaultValue}} of the parameter instead to globally scoped credentials.


For build "Authorization" (enabled by Authorize Project), I set the job to run as a user with access to the global credentials (I would have used credentials scoped to the user only, but you can't use these as default values). When selecting "Build with Parameters" as any other user, only the user scoped credentials are available.

Other users can still pass parameters to the job and successfully run it if they have the correct credentials. - If they try to run the job without specifying their own credentials, they can not access the default credentials and the job fails as desired. - (still working on restricting access to the credentials)

When initiated by timer, it uses the default globally scoped credentials and successfully runs.

info+jenkinsci@csullivan.net (JIRA)

unread,
Jan 29, 2019, 10:23:03 AM1/29/19
to jenkinsc...@googlegroups.com
Christopher Sullivan updated an issue
 
Change By: Christopher Sullivan
Comment:
I worked around this issue by using the [Authorize Project plugin|https://wiki.jenkins.io/display/JENKINS/Authorize+Project+plugin]. Instead of passing the credentials from the upstream job, I set the {{defaultValue}} of the parameter instead to globally scoped credentials.

For build "Authorization" (enabled by Authorize Project), I set the job to run as a user with access to the global credentials (I would have used credentials scoped to the user only, but you can't use these as default values). When selecting "Build with Parameters" as any other user, only the user scoped credentials are available.

Other users can still pass parameters to the job and successfully run it if they have the correct credentials.- If they try to run the job without specifying their own credentials, they can not access the default credentials and the job fails as desired.- (still working on restricting access to the credentials)


When initiated by timer, it uses the default globally scoped credentials and successfully runs.
Reply all
Reply to author
Forward
0 new messages