Describe the bug
When calling vaultRotateSecretId with jenkinsToken, jenkinsUsername, or jenkinsUrl
as explicit Groovy parameters containing Jenkins credential IDs, the credential values are
never resolved. The Go binary receives the credential ID string literally instead of the
actual secret value, causing authentication to fail.
Root Cause
vars/vaultRotateSecretId.groovy calls piperExecuteBin with an empty credential info list:
piperExecuteBin(parameters, STEP_NAME, METADATA_FILE, [], ...)
Because of this empty list, the Groovy layer never invokes withCredentials for
jenkinsToken, jenkinsUsername, or jenkinsUrl. All parameters are serialized as-is
into PIPER_parametersJSON and forwarded to the Go binary as literal strings.
Parameters marked as secret: true in resources/metadata/vaultRotateSecretId.yaml
are therefore never resolved via the Jenkins credential store.
Steps to Reproduce
Call the step with explicit Jenkins credential parameters:
vaultRotateSecretId script: script,
jenkinsUsername: 'myuser',
jenkinsUrl: 'https://my-jenkins.example.com',
jenkinsToken: 'MY_JENKINS_CREDENTIAL_ID'
Expected behavior
The Jenkins credential ID MY_JENKINS_CREDENTIAL_ID should be resolved via
withCredentials and the actual secret value should be passed to the Go binary.
Actual behavior
The literal string "MY_JENKINS_CREDENTIAL_ID" is passed to the Go binary, which
attempts to use it as the actual token value, causing the Jenkins connection to fail
with one of these errors:
could not write secret back to secret store jenkins: Connection Failed,
Please verify that the host and credentials are correct.
or, if jenkinsUrl resolves to an empty string:
could not write secret back to secret store jenkins:
Get "/api/json": unsupported protocol scheme ""
Suggested Fix
Add the Jenkins credential bindings to the credentialInfo list passed to
piperExecuteBin in vars/vaultRotateSecretId.groovy, similar to how other
piper steps handle secret parameters.
Workaround
Store url, userId, and token in Vault under $(vaultBasePath)/GROUP-SECRETS/jenkins.
The Go binary has a native Vault client and resolves them directly from Vault,
bypassing the Jenkins credential store entirely.
Library version
github.com/SAP/jenkins-library v1.500.0 (and likely earlier versions)
Describe the bug
When calling
vaultRotateSecretIdwithjenkinsToken,jenkinsUsername, orjenkinsUrlas explicit Groovy parameters containing Jenkins credential IDs, the credential values are
never resolved. The Go binary receives the credential ID string literally instead of the
actual secret value, causing authentication to fail.
Root Cause
vars/vaultRotateSecretId.groovycallspiperExecuteBinwith an empty credential info list:Because of this empty list, the Groovy layer never invokes
withCredentialsforjenkinsToken,jenkinsUsername, orjenkinsUrl. All parameters are serialized as-isinto
PIPER_parametersJSONand forwarded to the Go binary as literal strings.Parameters marked as
secret: trueinresources/metadata/vaultRotateSecretId.yamlare therefore never resolved via the Jenkins credential store.
Steps to Reproduce
Call the step with explicit Jenkins credential parameters:
Expected behavior
The Jenkins credential ID
MY_JENKINS_CREDENTIAL_IDshould be resolved viawithCredentialsand the actual secret value should be passed to the Go binary.Actual behavior
The literal string
"MY_JENKINS_CREDENTIAL_ID"is passed to the Go binary, whichattempts to use it as the actual token value, causing the Jenkins connection to fail
with one of these errors:
or, if jenkinsUrl resolves to an empty string:
Suggested Fix
Add the Jenkins credential bindings to the
credentialInfolist passed topiperExecuteBininvars/vaultRotateSecretId.groovy, similar to how otherpiper steps handle secret parameters.
Workaround
Store
url,userId, andtokenin Vault under$(vaultBasePath)/GROUP-SECRETS/jenkins.The Go binary has a native Vault client and resolves them directly from Vault,
bypassing the Jenkins credential store entirely.
Library version
github.com/SAP/jenkins-library v1.500.0 (and likely earlier versions)