This is really difficult to add to our automated tests because it requires a private repository and for us to either set that situation up during the tests OR include credentials in the integration-cli code.

ping @dmp42 I think this should fix your issue.

ping @stevvooe @RichardScothern @dmcgowan
also ping @icecrime

@jlhawn What change broke this?

@stevvooe I think it' was @duglin's changes in #12009

LGTM

@jlhawn just to make sure I fully understand what happened... in #12009 we moved the auth stuff in the config file down one level and so when we serialized that info there was now an extra wrapper around the auth stuff. Your fix, pretty much, removes the extra wrapper (so now its just a map) like we used to encode in the header before the other PR. Right?

@jlhawn I could reproduce the issue, and your PR indeed fixes it, not only on top of master but also cherry-picked on top of 1.7.0

I'll LGTM this because it makes sense to me, but I wanna make sure @duglin is also okay with this fix before merging :)

@duglin yep, that's correct.

LGTM - too bad we can't write a testcase :-(

Thanks guys

cherry picked into 1.7.1

Does this change affect all API versions? Can a client using API version 1.18 still send an old-style X-Registry-Auth header? I ask because users of Compose (which uses 1.18) and docker-py are experiencing issues due to this and we'd like to fix it.

It's easy enough to update Compose to use API version 1.19 and require Docker 1.7 or later, but docker-py supports older API versions and it's important that they remain stable.

@aanand I believe this change reverted the change in 1.7 where the /build endpoint expected the new ~/.docker/config file format:

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
            "email": "[email protected]"
        }
    }
}

This patch goes back to using the original format of ~/.dockercfg:

{
    "https://index.docker.io/v1/": {
        "auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
        "email": "[email protected]"
    }
}

is this not fixed yet? I am running 1.7.1 and still getting image not found from private repo

@MrMMorris This was included in Docker 1.7.1 (both your Docker client and daemon should be updated).

If you're having an issue with a private repository on the Docker Hub Registry, then I would recommend contacting their support folks. If you're running a private Registry from https://github.com/docker/distribution then I'd try opening an issue there or checking their IRC channel (#docker-distribution on irc.freenode.net).

@jlhawn yep, I was definitely running an old version of client (1.4.1), but after brew update && brew upgrade docker, I still get image company/blah:latest not found.

$ docker -v
Docker version 1.7.1, build 786b29d

This is pulling from Docker Hub using docker-compose up

oh, okay, then I guess that would be what @aanand was mentioning above (he's a maintainer of docker-compose which uses docker-py).

@MrMMorris if you do a manual pull using docker pull company/blah:latest does that also fail? and did you remember to do a docker login first?

@aanand are docker-compose and docker-py aware that the config file has been moved from ~/.dockercfg to ~/.docker/config.json?

I think you can also use an environment variable now to specify the location of the config directory.

@jlhawn I am definitely logged in. Manual pull works as does the workaround detailed in the ticket referenced below.

I think @aanand is aware. This is the ticket that eventually lead me here: docker/compose#1577. I guess something still has to be done on the compose side?

@MrMMorris What version of Compose are you using? The fix for not reading ~/.docker/config.json was released in 1.3.2.

@aanand hello again 😄

As in the other ticket, I am running 1.4.0rc2.

Hey, I initially reported #14092 which is supposedly fixed in 1.7.1. But it actually doesn't work for my usecase (through the docker-java client) and now I'm slightly confused. Is there a change needed in the actual client for the build endpoint?

Hi,

Just wanted to say that we are also experiencing this issue. If you do a docker login, then pull the image from the private repo on dockerhub that works fine. If you do a docker build from a dockerfile which has a FROM then it reports that the image is not found. Our docker on that machine is running on Docker version 1.9.1, build a34a1d5/1.9.1

@rashtisouciance This PR was merged over a year ago, so I am not sure that this is the same issue. I'd recommend hitting the support forums or filing a second issue if you are looking to find a solution.

In the future, I'd recommend not commenting on closed or merged PRs. Often times, issues with similar behavior can have completely different root causes, especially if the behavior is encountered after a large period of time (you are running 1.9.1 and this was fixed in 1.7.1).