Closed toothbrush closed 6 months ago
Looking at one of our agents, here is what i get:
[ssm-user@ip-172-18-13-243 bin]$ docker-compose --version
Docker Compose version v2.20.2
So it looks like docker-compose
(which is the command the plugin uses here) turns into v2 on our system.
I did a bit more digging, and it turns out that docker-compose
on our Buildkite boxes is actually a script which essentially forwards all arguments to docker compose --compatibility "$@"
, so i guess the version reporting v2 isn't a surprise. Perhaps something weird is happening such that --compatibility
doesn't change the -
or _
tag separator discrepancy 🤔
That is really weird as it looks like your installation does not respect the compatibility
flag whatsoever because the image is getting built with a -
in its name:
6 naming to docker.io/library/buildkite018b4b17238a4a8a95d3497da7cdfedf-app done
In theory, --compatibility
should change that to buildkite018b4b17238a4a8a95d3497da7cdfedf-app
and that is what the plugin assumes through the replication of the corresponding information.
In #418 I tried simplifying the code through the use of config --images
but not only that flag is only available from 2.20+ (so not all CLI v2 would have it) but also it prints images for the service and its dependencies and not just a single specified service. Which means that this plugin still needs to replicate the compose behaviour of using -
in v2 and _
in v1 or v2 with compatibility. :shrug:
While working on #420 we were able to duplicate this issue exactly. The issue was that the plugin defaults to cli V1 (docker-compose
) but the docker installation in the agent running the job actually had cli V2 (docker compose) installed with a V1 wrapper that forwarded calls to the V2 CLI without the compatibility
flag.
That means that the plugin assumed V1 but internally it was running V2 so the code to calculate the automatic image names did the wrong thing due to the messy setup.
Luckily, the upcoming release that will default to V2 should completely eliminate this issues as I can not think of an installation that would create a docker plugin called compose
to wrap V2 calls and actually call cli V1.
I just got bitten by what looks like the same issue as https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/issues/352 which led me to https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/pull/353.
This is my pipeline:
Here's what happens:
The eagle-eyed reader will see a problem:
...97da7cdfedf-app
versus...97da7cdfedf_app
as the image name.I haven't found where this default is coming from (i'll investigate and update the issue), but it seems our Buildkite agents are defaulting to CLI version 2 whereas the plugin is assuming we're on v1. However, specifying
cli-version: 2
fixed the issue. I'm wondering if i should try and cook up a PR that either robustly works out which CLI version we're using, or working out the name of the image we just built.