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

41 views
Skip to first unread message

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 7:53:03 AM10/14/19
to jenkinsc...@googlegroups.com
Art V created an issue
 
Jenkins / Task JENKINS-59777
nested docker.withRegistry() does not work
Issue Type: Task Task
Assignee: Unassigned
Components: docker-workflow-plugin
Created: 2019-10-14 11:52
Environment: Jenkins 2.190.1
docker-workflow-plugin 1.21
Priority: Minor Minor
Reporter: Art V

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?
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:00:01 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an issue
Change By: Art V
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: 
{code:java}

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')
        }
    }
}
{code}

 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`

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:00:02 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an issue
Change By: Art V
Component/s: docker-commons-plugin

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:01:02 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an issue
Change By: Art V
Environment: Jenkins 2.190.1
docker-workflow-plugin 1.21
docker-commons 1.15

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:15:02 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an issue
Change By: Art V
Issue Type: Task Bug

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:18:02 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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]

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 14, 2019, 8:19:02 AM10/14/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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]

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 15, 2019, 7:53:03 AM10/15/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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: [https://github.com/jenkinsci/docker-commons-plugin/pull/82]

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 15, 2019, 7:56:05 AM10/15/19
to jenkinsc...@googlegroups.com
Art V assigned an issue to Jesse Glick
Change By: Art V
Assignee: Jesse Glick

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 15, 2019, 8:18:03 AM10/15/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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: [https://github.com/jenkinsci/docker-commons-plugin/pull/82]

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 15, 2019, 8:19:03 AM10/15/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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: [https://github.com/jenkinsci/docker-commons-plugin/pull/82]

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 15, 2019, 8:19:03 AM10/15/19
to jenkinsc...@googlegroups.com
Art V updated an 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: 
{code:java}
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')
        }
    }
}
{code}
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: [https://github.com/jenkinsci/docker-commons-plugin/pull/82]

jglick@cloudbees.com (JIRA)

unread,
Oct 16, 2019, 10:51:03 AM10/16/19
to jenkinsc...@googlegroups.com
Jesse Glick started work on Bug JENKINS-59777
 
Change By: Jesse Glick
Status: Open In Progress

jglick@cloudbees.com (JIRA)

unread,
Oct 16, 2019, 10:51:03 AM10/16/19
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Art V
Change By: Jesse Glick
Assignee: Jesse Glick Art V

jglick@cloudbees.com (JIRA)

unread,
Oct 16, 2019, 10:51:04 AM10/16/19
to jenkinsc...@googlegroups.com
Change By: Jesse Glick
Status: In Progress Review

jglick@cloudbees.com (JIRA)

unread,
Oct 16, 2019, 10:53:03 AM10/16/19
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-59777
 
Re: nested docker.withRegistry() does not work

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"'.

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 17, 2019, 3:29:02 AM10/17/19
to jenkinsc...@googlegroups.com
Art V commented on Bug JENKINS-59777

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 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.

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 17, 2019, 3:30:01 AM10/17/19
to jenkinsc...@googlegroups.com
Art V commented on Bug JENKINS-59777

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

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 17, 2019, 6:21:03 AM10/17/19
to jenkinsc...@googlegroups.com
Art V assigned an issue to Jesse Glick
Change By: Art V
Assignee: Art V Jesse Glick

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 17, 2019, 6:22:02 AM10/17/19
to jenkinsc...@googlegroups.com
Art V edited a comment on Bug JENKINS-59777
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.

jglick@cloudbees.com (JIRA)

unread,
Oct 17, 2019, 9:51:03 AM10/17/19
to jenkinsc...@googlegroups.com

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.

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 17, 2019, 10:05:03 AM10/17/19
to jenkinsc...@googlegroups.com
Art V commented on Bug JENKINS-59777

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.

jglick@cloudbees.com (JIRA)

unread,
Oct 17, 2019, 10:13:02 AM10/17/19
to jenkinsc...@googlegroups.com

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.

arthur.vanduynhoven@gmail.com (JIRA)

unread,
Oct 18, 2019, 3:36:05 AM10/18/19
to jenkinsc...@googlegroups.com
Art V commented on Bug JENKINS-59777

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

Reply all
Reply to author
Forward
0 new messages