I can reproduce Nick's issue, and my own notice of it arose in a similar context

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

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.

Possibly a duplicate of JENKINS-35490?

I am currently running into what I believe to be the same issue as maskmaster. 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.

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

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