SecretText vs File Credentials: Binding to Environment Variables or Temporary Files in Jenkins Pipelines?

Direct answer

No built-in binding writes a SecretText value to a temporary file. secretText and string bindings expose the secret only as an environment variable inside the withCredentials block. If your downstream script strictly requires a file path, use a File credential, or manually write the SecretText variable to a private file and delete it before the block ends.

Yes. You can bind multiple SecretText credentials in one withCredentials call, provided each binding uses a distinct variable name. The one-per-type limit is not general plugin behavior.

Likely explanation

The "unsupported binding" error you reported is consistent with passing a SecretText credential ID to file(). The plugin expects file() to reference a File credential; it does not auto-materialize text secrets to disk.

Behavior to verify in your environment

• File credentials bind to a temporary file path variable scoped to the withCredentials block.
• SecretText bindings bind to an environment variable only.
• Temporary-file location, console masking, and cleanup depend on Jenkins core and Credentials Binding plugin versions.
• This assumes the plugin is installed, the credential IDs exist, and the build has permission to use them.

Steps for this case

1. Use a File credential when the tool needs a path:

withCredentials([file(credentialsId: 'integration-token-file', variable: 'TOKEN_FILE')]) {
    sh './run-integration-tests.sh --token-file "$TOKEN_FILE"'
}

1. Reuse a SecretText credential by writing it yourself:

withCredentials([string(credentialsId: 'integration-token-text', variable: 'TOKEN')]) {
    def secretFile = "${env.HOME}/.jenkins-secrets/token-${env.BUILD_ID}.txt"
    sh "mkdir -p \$(dirname ${secretFile}) && chmod 700 \$(dirname ${secretFile})"
    writeFile(file: secretFile, text: env.TOKEN)
    try {
        sh "chmod 600 ${secretFile} && ./run-integration-tests.sh --token-file ${secretFile}"
    } finally {
        sh "rm -f ${secretFile}"
    }
}

1. Bind several tokens at once with distinct names:

withCredentials([
    string(credentialsId: 'token-a', variable: 'TOKEN_A'),
    string(credentialsId: 'token-b', variable: 'TOKEN_B')
]) {
    sh './run-integration-tests.sh --token-a "$TOKEN_A" --token-b "$TOKEN_B"'
}

Verification

Run this in a non-production test job:

withCredentials([
    string(credentialsId: 'test-secret-text', variable: 'TOKEN'),
    file(credentialsId: 'test-secret-file', variable: 'SECRET_FILE')
]) {
    sh 'echo TOKEN_SET; echo "FILE=$SECRET_FILE"; test -f "$SECRET_FILE" && echo FILE_EXISTS'
}

After the block completes, confirm the temporary file path no longer exists and that console output shows masked values rather than the secret. Avoid echoing $TOKEN or passing it as a command argument where it can be logged; environment-variable masking does not protect file contents or child-process argument lists.

Missing diagnostic detail

Does your downstream script accept the token through standard input, or does it strictly require a file path? If it accepts stdin, you can avoid writing the secret to disk entirely.