Skip to content

[JENKINS-76019] docker.withRegistry should support a list of registries and credentials #732

@jenkins-infra-bot

Description

@jenkins-infra-bot

docker.withRegistry specifies authentication for a single docker repo.  That's usually sufficient for a traditional docker build where `docker push` is straightforward and you are pushing to a single repo.

But that doesn't work well with multi-architecture docker builds.  The workflow has changed, so expected usage is to build and publish in the same command, including publishing to all locations.  

In my case I need to build multi-architecture docker images and push to both a local and a cloud repo.  I need to authenticate to two or more repos at the same time, but `docker.withRegistry()` does not support that.

  • Separate docker push commands are challenging because of limitations in the docker local cache, plus you need to push all images, then build and push a manifest.
  • Previously `docker.withRegistry()` supported nesting, but that was broken, see JENKINS-59777
  • Docker recommendation is `docker login` but that has potential conflicts on a shared agent, and credentials are even more exposed

The scenario of multi-architecture docker builds raises the priority of some way to safely authenticate to multiple repos at once, and the alternative approaches are much less desirable.  `docker.withRegistry()` should support a list or some other way of specifying multiple sets of login information.

 

I should be able to do something like

docker.withRegistry(['https://repo1.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd',
    ['https://repo2.public.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd']) {
    sh('docker buildx build --builder builder-17bb5f59-a5a1-4124-a0a0-b30e8a5e0d57 --platform linux/amd64,linux/arm64 --no-cache --provenance=false -f Dockerfile --tag repo1.private.com/my_images/image:1.2.3 --tag repo2.public.com/my_images/image:1.2.3 --push .')
}

 


Originally reported by wgc1929, imported from: docker.withRegistry should support a list of registries and credentials
  • status: Open
  • priority: Major
  • component(s): docker-workflow-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 1
  • imported: 2025-12-07
Raw content of original issue

docker.withRegistry specifies authentication for a single docker repo.  That's usually sufficient for a traditional docker build where `docker push` is straightforward and you are pushing to a single repo.

But that doesn't work well with multi-architecture docker builds.  The workflow has changed, so expected usage is to build and publish in the same command, including publishing to all locations.  

In my case I need to build multi-architecture docker images and push to both a local and a cloud repo.  I need to authenticate to two or more repos at the same time, but `docker.withRegistry()` does not support that.

  • Separate docker push commands are challenging because of limitations in the docker local cache, plus you need to push all images, then build and push a manifest.
  • Previously `docker.withRegistry()` supported nesting, but that was broken, see JENKINS-59777
  • Docker recommendation is `docker login` but that has potential conflicts on a shared agent, and credentials are even more exposed

The scenario of multi-architecture docker builds raises the priority of some way to safely authenticate to multiple repos at once, and the alternative approaches are much less desirable.  `docker.withRegistry()` should support a list or some other way of specifying multiple sets of login information.

 

I should be able to do something like

docker.withRegistry(['https://repo1.private.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd',
                    ['https://repo2.public.com', '5d243c54-3d2c-42e3-9c3d-35c1cbe61ddd']) {
    sh('docker buildx build --builder builder-17bb5f59-a5a1-4124-a0a0-b30e8a5e0d57 --platform linux/amd64,linux/arm64 --no-cache --provenance=false -f Dockerfile --tag repo1.private.com/my_images/image:1.2.3 --tag repo2.public.com/my_images/image:1.2.3 --push .')
}

 

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions