-
Bug
-
Resolution: Incomplete
-
Major
-
None
-
1.6.5
1. Try to use a private registry in the Image id/tag. eg:
docker.mycompany.com/my-bucket/ubuntu
2. Setup the credentials for Docker registry credentials.
3. Run the project
It fails to pull the image
Error: Status 403 trying to pull repository my-bucket/ubuntu: "
"
Look closer to the .dockercfg generated on the host: It's always: https://index.docker.io/v1
{"https://index.docker.io/v1":
{ "auth": ".......", "email": "my-crediential" }}It seems in the plugin code that when it creates the registryEndpoint, it call with 'null' on URL:
this.registryEndpoint = new DockerRegistryEndpoint(null, credentialsId);
And the docker-common will use its default index.docker.io/v1 instead of the one defined in image tag.
I'm not sure how it will work, it seems the code is setting up the credential first and then pull in the container image, so the image ID is never consulted when it tries to create the registryEndpoint, so it seems it will always be the default index.docker.io/v1.
We are actually not using private registry, but a different public one, like quay.io, and it's not working because of this.
I thought it's supported because it's coming from the help:
........ or the Docker image you have configured for this build do point to a private registry "docker.mycompany.com/my-bucket/ubuntu:secret-version" - either as an image ID or parent FROM reference in Dockerfile - then specify the registry credentials here so docker command line client is configured accordingly and can pull from this registry.
(from CloudBees Docker Custom Build Environment Plugin)
- duplicates
-
JENKINS-51406 Integrate with new docker login APIs
-
- Open
-
- relates to
-
-
- Resolved
-
[JENKINS-33985] Credentials always points to https://index.docker.io/v1 even for private registry
Carlton Brown
added a comment - This seems to be getting triggered by JENKINS-344967
Scenario:
- I am using a private registry at mycompany.com. Inspect contents of ~/.docker/config.json and my private registry auth is correct.
- I set up a build using a totally private image, and select the credentials of my private registry.
- Run build, it fails with error: "Unable to find image 'alpine:3.2' locally". Whaat? I'm not even using alpine 3.2: Oh wait, THIS PLUGIN ITSELF USES ALPINE 3.2. (See JENKINS-344967)
- And now my config.json has created an auth entry for DockerHub, but it uses my internal auth credentials.
- "https://index.docker.io/v1/": {
"auth": "Greetings Docker Hub, this plugin wants to leak a private registry token",
"email": "internal@mycompany.com"
}
Carlton Brown
added a comment - This seems to be getting triggered by JENKINS-344967
Scenario:
I am using a private registry at mycompany.com. Inspect contents of ~/.docker/config.json and my private registry auth is correct.
I set up a build using a totally private image, and select the credentials of my private registry.
Run build, it fails with error: "Unable to find image 'alpine:3.2' locally". Whaat? I'm not even using alpine 3.2: Oh wait, THIS PLUGIN ITSELF USES ALPINE 3.2. (See JENKINS-344967 )
And now my config.json has created an auth entry for DockerHub, but it uses my internal auth credentials.
"https://index.docker.io/v1/": {
"auth": "Greetings Docker Hub, this plugin wants to leak a private registry token",
"email": "internal@mycompany.com"
}
Niek Geerts
added a comment - I've been having the same problem, now exacerbated by JENKINS-34967 as well. Whereas a workaround which removes the erroneous credentials used to work, builds now fail immediately as the private credentials are used in an attempt to download alpine:3.2 from Docker Hub. Quite frankly, I question the need for Docker Commons Plugin to write in the docker config file at all, but I suppose there's a better place to raise that issue.
Niek Geerts
added a comment - I've been having the same problem, now exacerbated by JENKINS-34967 as well. Whereas a workaround which removes the erroneous credentials used to work, builds now fail immediately as the private credentials are used in an attempt to download alpine:3.2 from Docker Hub. Quite frankly, I question the need for Docker Commons Plugin to write in the docker config file at all, but I suppose there's a better place to raise that issue. As of JENKINS-38018 the plugin will normally just run docker login (with a freshly allocated config directory), so this is probably obsolete.
…though if you are using the Docker Custom Build Environment plugin rather than Docker Pipeline, you would need to wait for JENKINS-51406 to pick up the change.
I notice the same. If I use private repository credentials, this plugin adds a bogus entry for dockerhub into ~/.docker/config