Credential Handling Reference
This reference explains how JSL resolves credentials, what credential IDs are expected today, and how to extend credential handling safely.
How JSL Resolves Credentials
JSL loads credentials through getCredentials(cacheKeyEnabled, projectType, buildEnv) and binds them with withCredentials(…) before build/deploy commands run.
-
Base credential set is chosen by
projectType(service,mock,library) -
Additional credentials are selected by
buildEnv(sandbox,staging,prod) -
Optional credentials are appended based on config flags (for example
cacheKeyEnabled)
Current Credential IDs Used by JSL
Environment-specific additions
-
sandbox-
VA_BITBT_USER -
VA_BITBT_PWD -
VA_JIRA_USER -
VA_JIRA_PWD
-
-
staging-
Username/password credential (ID:
69ff7537-da06-4304-8821-9d970c8f8738) bound toVA_BITBT_USER/VA_BITBT_PWD -
VA_JIRA_USER -
VA_JIRA_PWD
-
-
prod-
Username/password credential (ID:
2be89da0-461d-4af1-82ef-35f90dba4339) bound toVA_BITBT_USER/VA_BITBT_PWD
-
Adding a New Credential to JSL
-
Add the credential in Jenkins Credentials (global or folder scope).
-
Update
vars/getCredentials.groovyto bind it for the rightprojectTypeandbuildEnv. -
Use a stable variable name (
variable: 'MY_CRED') and keep naming consistent across environments. -
Consume it only inside
withCredentials { … }blocks in pipeline scripts. -
Update docs (Converting Projects to JSL + this reference) and note behavior changes in CHANGELOG.
Migration Guidance
-
Prefer named credentials over environment-specific random UUIDs where possible.
-
Keep credential IDs aligned across environments to reduce branching in JSL.
-
Avoid storing secrets in
jenkins.yaml; keep them in Jenkins Credentials and reference them indirectly. -
Validate credentials in
sandboxfirst, then promote tostaging/prod.