Summary

After upgrading credentials-plugin to 7.2.8 (released ~1 week ago), file-type secret credentials bound via withCredentials intermittently produce a config.json (Docker registry auth file) that fails authentication against a private Docker registry (Nexus). Downgrading to 7.2.5 resolves the issue immediately, with no other change.

Environment

• Jenkins core: 2.555.3 (LTS)
• credentials-plugin: 7.2.8 (broken) → downgraded to 7.2.5 (works)
• Credential type: Secret file (file binding), containing a Docker config.json with registry auth
• Registry: private Nexus Docker registry (nexus-services.mydomain.xx:15000)
• Agent OS: Linux

Symptom

Error response from daemon: Head "https://nexus-services.mydomain.xx:15000/v2/<repo>/manifests/latest": no basic auth credentials

Key observation: reproduces with a plain sh step, no Docker plugin involved

The failure is not specific to withDockerContainer, docker-workflow, container flags (--privileged, -u 0, --pull always), or any particular image. It reproduces with the simplest possible consumer of the binding — a direct docker push in a plain sh step:

withCredentials([file(credentialsId: dockerCredentials, variable: 'DOCKERCONFIGFILE')]) {
  env.DOCKER_CONFIG = DOCKERCONFIGFILE.take(DOCKERCONFIGFILE.lastIndexOf("/"))
  sh "docker push ${pushString}"
}

This fails with 7.2.8 and succeeds with 7.2.5, with no other change to the pipeline. This rules out any interaction with docker-workflow, container runtime flags, or the specific image/repo — the problem is isolated to how the file credential binding materializes the secret on disk in 7.2.8.

Additional intermittent behavior observed

Within the same pipeline run (same job, same credential, same registry, same agent), different steps consuming the identical secret file sometimes succeeded and sometimes failed:

• A step using withDockerContainer(image: ..., args: "--network host") (no --pull always) — succeeded
• A step using withDockerContainer(image: ..., args: "--network host --privileged -u 0 --pull always") — failed
• A plain sh "docker push" using the same binding — also failed

Notably, manually running docker --config <path> login/pull from the shell, using the exact same secret file path generated by the pipeline's withCredentials block on the same agent, succeeded. This means the credential content itself is valid and the file is readable/correct when accessed manually outside of the pipeline step context — yet the same file, read by a step inside the same pipeline run, fails.

This inconsistency (identical file, identical registry/credential, different outcome depending on whether it's read manually via CLI vs. by a step inside the running pipeline) suggests the problem is not the file's content itself, but something about how/when the file is read relative to how it's written/finalized by the 7.2.8 binding during pipeline execution — pointing to a timing or lifecycle issue in the binding rather than a static content corruption.

Steps to reproduce

1. Configure a Secret file credential in Jenkins containing a valid Docker config.json for a private registry.
2. In a Declarative or Scripted pipeline, use:

            withCredentials([file(credentialsId: repos.docker.credentials, variable: 'DOCKERCONFIGFILE')]) {
              env.DOCKER_CONFIG = DOCKERCONFIGFILE.take(DOCKERCONFIGFILE.lastIndexOf("/"))
              withDockerContainer(image: "${image}:${imageTag}", args: "--network host --privileged -u 0 --pull always") {

3. Run with credentials-plugin 7.2.8 → intermittent/failing auth ("no basic auth credentials").
4. Downgrade to 7.2.5, re-run with no other changes → succeeds consistently.

Expected behavior

The secret file should be fully and correctly written to disk before being made available to any step inside the withCredentials block, and its content/auth should be identical to what a manual docker login/pull with the same underlying credential would produce.

Additional notes

• The credential/registry itself is confirmed valid: the exact secret file generated by the pipeline, tested manually via CLI on the same agent, authenticates successfully. The failure only occurs when the file is consumed by a step running inside the same pipeline execution.
• Happy to provide further logs/timing data if useful for triage.