[JENKINS-59777] nested docker.withRegistry() does not work

[jenkins-infra-bot]

With the previous behavior of docker-workflow-plugin (1.15) I was able to nest my `docker.withRegistry()` calls so I can access numerous registries at the same time.

Example: 

node('docker') {
    docker.withRegistry('https://repo1.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd') {
docker.withRegistry('https://repo2.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd') {
    sh('docker pull repo1/library/image:latest')
    sh('docker pull repo2/libraryimage:latest')
}
    }
}

From the output it looks like each credential is stored in it's own file per registry. My assumption is that with nested logins, it should be in the same credential store/file?

Is there any workaround for this?

 

• Update – after more investigation – think this is more related to the docker-commons plugin - think it's related to this MR: https://github.com/jenkinsci/docker-workflow-plugin/pull/140/files
  This MR introduced the env variables - specifically `DOCKER_CONFIG`
• -Update – further investigation – there has been an update to docker-commons-plugin that fixed this issue with --https://issues.jenkins-ci.org/browse/JENKINS-52737---
  Made a MR for to use the latest docker-commons: [-https://github.com/[JENKINS-59777] Updated docker-commons to 1.15 #193-]
• Update – Fixes need on the docker-commons logic. MR here: [JENKINS-59777] Allow nested docker.withRegistry() blocks docker-commons-plugin#82

---

Originally reported by arty13, imported from: nested docker.withRegistry() does not work

• assignee: jglick
• status: In Review
• priority: Minor
• component(s): docker-commons-plugin, docker-workflow-plugin
• resolution: Unresolved
• votes: 5
• watchers: 7
• imported: 2025-12-07

Raw content of original issue

With the previous behavior of docker-workflow-plugin (1.15) I was able to nest my `docker.withRegistry()` calls so I can access numerous registries at the same time.

Example: 

node('docker') {
    docker.withRegistry('https://repo1.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd') {
        docker.withRegistry('https://repo2.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd') {
            sh('docker pull repo1/library/image:latest')
            sh('docker pull repo2/libraryimage:latest')
        }
    }
}


From the output it looks like each credential is stored in it's own file per registry. My assumption is that with nested logins, it should be in the same credential store/file?
Is there any workaround for this?
 

	
Update – after more investigation – think this is more related to the docker-commons plugin - think it's related to this MR: https://github.com/jenkinsci/docker-workflow-plugin/pull/140/files
 This MR introduced the env variables - specifically `DOCKER_CONFIG`
	
-Update – further investigation – there has been an update to docker-commons-plugin that fixed this issue with --https://issues.jenkins-ci.org/browse/JENKINS-52737---
 Made a MR for to use the latest docker-commons: [-https://github.com/jenkinsci/docker-workflow-plugin/pull/193-]
	
Update – Fixes need on the docker-commons logic. MR here: [JENKINS-59777] Allow nested docker.withRegistry() blocks docker-commons-plugin#82

environment

Jenkins 2.190.1<br/>
docker-workflow-plugin 1.21<br/>
docker-commons 1.15

[jenkins-infra-bot]

• Remote link associated with this issue:

  • [GitHub] Docker Commons Plugin PR #​82

[jenkins-infra-bot]

jglick:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  Did not follow most of this, but please use the Link feature in JIRA to link to any related issues.
  
  From a quick glance it looks like this issue would only affect the legacy mode of directly editing config files; by default the plugin will try to use CLI docker login. As a general recommendation, if in doubt just use the generic withCredentials and sh 'docker login -u "$USER" -p "$PASS"'.
  

Did not follow most of this, but please use the Link feature in JIRA to link to any related issues.

From a quick glance it looks like this issue would only affect the legacy mode of directly editing config files; by default the plugin will try to use CLI docker login. As a general recommendation, if in doubt just use the generic withCredentials and sh 'docker login -u "$USER" -p "$PASS"'.

[jenkins-infra-bot]

arty13:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  I cannot use the cli `docker login` approach as this would affect other pipelines running on the same node with different access rights.
  
  In my use case we use Artifactory where we have a virtual repo for reading and a dev repo for publishing our docker images. For example our dockerfile uses the virtual read repo for the `FROM` clause of the image.
   Artifactory uses it's own permissions to limit the access to different internal repos of the virtual repo access and using the cli `docker login` approach will overwrite the credentials allowing other pipelines to access things not allowed.
  
  So with the example above, this works in 1.15 of docker-workflow plugin, but any newer versions of the plugin only the last `docker.withRegistry()` works. So updating the logic of docker-commons, this above example will continue to work when using newer versions of docker-workflow plugin.
  

I cannot use the cli `docker login` approach as this would affect other pipelines running on the same node with different access rights.

In my use case we use Artifactory where we have a virtual repo for reading and a dev repo for publishing our docker images. For example our dockerfile uses the virtual read repo for the `FROM` clause of the image.
Artifactory uses it's own permissions to limit the access to different internal repos of the virtual repo access and using the cli `docker login` approach will overwrite the credentials allowing other pipelines to access things not allowed.

So with the example above, this works in 1.15 of docker-workflow plugin, but any newer versions of the plugin only the last `docker.withRegistry()` works. So updating the logic of docker-commons, this above example will continue to work when using newer versions of docker-workflow plugin.

[jenkins-infra-bot]

arty13:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  Merge request on docker-commons to have this behavior work as it did previously with docker-workflow 1.15 plugin
  

Merge request on docker-commons to have this behavior work as it did previously with docker-workflow 1.15 plugin

[jenkins-infra-bot]

jglick:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  this would affect other pipelines running on the same node with different access rights
  
  Well, you can set an environment variable for the config location, but of course in this setup you have no real security anyway (including when using withRegistry)—you should use one-shot agents if at all possible.
  

this would affect other pipelines running on the same node with different access rights

Well, you can set an environment variable for the config location, but of course in this setup you have no real security anyway (including when using withRegistry)—you should use one-shot agents if at all possible.

[jenkins-infra-bot]

arty13:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  I'm hoping to get to one-shot agents (pushing for JenkinsX when it supports GitLab/Artifactory appropriately) but due to various teams/groups and the current state of our CI I am unable to do this at the moment.
  We also have a tendency to never want to update Jenkins and the installed plugins due to no one wanted to manage this. So I've been trying to keep Jenkins and the plugins up to date, but I keep having to hold off on updating the docker-workflow plugin due to this change in behavior. So I decided to look into it and provide a fix/PR for this scenario.
  
  And to implement your last suggestion; I would need to update our 100+ workflows and that would take time that gives very little end benefit when the long term goal is to move towards JenkinsX.
  
  So if this proposed change will not be accepted then okay; then I will stay on an older version of the plugin until I've switched to JenkinsX.
  

I'm hoping to get to one-shot agents (pushing for JenkinsX when it supports GitLab/Artifactory appropriately) but due to various teams/groups and the current state of our CI I am unable to do this at the moment.
We also have a tendency to never want to update Jenkins and the installed plugins due to no one wanted to manage this. So I've been trying to keep Jenkins and the plugins up to date, but I keep having to hold off on updating the docker-workflow plugin due to this change in behavior. So I decided to look into it and provide a fix/PR for this scenario.

And to implement your last suggestion; I would need to update our 100+ workflows and that would take time that gives very little end benefit when the long term goal is to move towards JenkinsX.

So if this proposed change will not be accepted then okay; then I will stay on an older version of the plugin until I've switched to JenkinsX.

[jenkins-infra-bot]

jglick:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  I have no idea if it will be accepted; I do not maintain this plugin. Just noting the general workaround for any issues with this class of problem.
  

I have no idea if it will be accepted; I do not maintain this plugin. Just noting the general workaround for any issues with this class of problem.

[jenkins-infra-bot]

arty13:

• Comment link
• Original comment link (no redirect)
• Raw content of original comment:

  Thanks for the info on the workaround. Hopefully it helps others for their scenarios 
  

Thanks for the info on the workaround. Hopefully it helps others for their scenarios