-
Bug
-
Resolution: Unresolved
-
Minor
Because of the presence of the ignoreMissing option for the sshagent() Workflow step, one might assume that the absence of a credential will result in a failed build. Or at the very least that the contents of the sshagent() {} block would not execute.
Neither is the case unfortunately.
With the following workflow:
node {
sshagent(["non-existent-garbage"]) {
unstash "foo"
sh "ls"
}
}
The following will occur:
[Workflow] Allocate node : Start
Running on Docker-bb75aee9cf85 in /home/jenkins/workspace/multipass/master
[Workflow] node {
[Workflow] SSH Agent : Start
FATAL: [ssh-agent] Could not find specified credentials
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] Java/JNR ssh-agent
[ssh-agent] Started.
[Workflow] sshagent {
[Workflow] unstash
[Workflow] sh
[master] Running shell script
+ ls build/archives
jenkins.io-2.0.35+3e5ba13.zip
[Workflow] } //sshagent
[Workflow] SSH Agent : End
[Workflow] } //node
[Workflow] Allocate node : End
[Workflow] End of Workflow
Finished: SUCCESS
There does not seem to be any way to prevent the execution of the block if the credentials are missing.
- is duplicated by
-
-
- Resolved
-
- links to
[JENKINS-32104] Failing to find credentials doesn't actually fail a Workflow
Timothy Clarke
added a comment - Possibly a little out of scope for this exact issue, but it would be nice if the error was able to distinguish between could not find key, and unable to access key eg out of scope.
The following is when updating the key in credentials manager
I spent a while on this one because the snippet generator happy generated syntax with the key even when sshagent could never access the key
Timothy Clarke
added a comment - Possibly a little out of scope for this exact issue, but it would be nice if the error was able to distinguish between could not find key, and unable to access key eg out of scope.
The following is when updating the key in credentials manager
I spent a while on this one because the snippet generator happy generated syntax with the key even when sshagent could never access the key
the snippet generator happy generated syntax with the key even when sshagent could never access the key
That would be a distinct bug if true—the doFillCredentialsIdItems or whatever should use the same lookup algorithm.
Code changed in jenkins
User: R. Tyler Croy
Path:
Jenkinsfile
http://jenkins-ci.org/commit/jenkins.io/ff3bc09b643da104c514798098a735f8fff591b3
Log:
Add support for deploying the built zip out to the beta site
The following tickets were created as a result of this experimentation:
JENKINS-32101JENKINS-32102