docker-compose override file causes daemon connection failure

[GaryPWhite]

We're seeing some strange behavior from the injected docker-compose override. To reproduce, I yanked a command from a build step and went into our buildkite-agent box as the relevant user to reproduce the following:

# works (switched the order of the compose-buildkite-override)
docker-compose -f docker-compose.buildkite-40-override.yml -f docker-compose.yaml -p buildkitebd708876a67b45b88f1445f0baeca6e6  build --pull devbox
# doesn't work (original command)
docker-compose -f docker-compose.yaml -p buildkitebd708876a67b45b88f1445f0baeca6e6 -f docker-compose.buildkite-40-override.yml build --pull devbox

output we're seeing from non-working command : Couldn't connect to Docker daemon at http+docker://localhost - is it running? -- something we don't get when running docker-compose in our other pipelines / builds. It appears to me something about the injected override file is dis-allowing us from connecting to the docker agent.

Wondering if we could get some ideas here or guidance on how we can fix this in the plugin or if we're doing something wrong.

[bohao-cao]

I am the "relevant user". It looks like the error relates to the casing of image-repository and image-name. When giving all lower case names, the error is gone. However the error message exposed doesn't give a hint on the value casing.

[lox]

Thanks for the report folks, we haven't seen this before, will try and reproduce. Any idea what docker and docker-compose version y'all are using?

[GaryPWhite]

Docker version 17.09.1-ce docker-compose version 1.23.2

[jufemaiz]

@lox I can confirm that I'm seeing this too. Fresh buildkite elastic-ci stack.

https://buildkite-community.slack.com/archives/C19BG77H9/p1565827180030100

The difference for me is that it's causing issues regardless of position.

[toote]

From the conversation in slack and second comment, this error was due to an issue with an invalid tag name (not sure if the image repository would cause this as well but it is possible). I will close this one in favor of working on this on #233 but feel free to re-open it if there is something missing