If the image has been pre-built and pushed, it'd be nice to show a message in a post-command hook for how to re-run the step locally.

For example:

docker pull "${image}" && \
echo -e "services:\n\t${service}:\n\t\timage: \"${image}\"" \
  > "/tmp/buildkite-job-${job_id}.docker-compose.yml" && \
docker-compose run \
  -it \
  --rm \
  -f "/tmp/${job_id}.docker-compose.yml" \
  --name "buildkite-job-${job_id}" \
  "${service}" "${command}";
rm "/tmp/buildkite-job-${job_id}.docker-compose.yml"

Is their any way to force the plugin to always pull a fresh version of a pre-built image, I would normally do a docker-compose pull locally but I don't have the option of doing that here?

This is a feature request .. just to be clear, not expecting this behavior, but would be nice since it seems like its needed by everyone just about ..

I had to write a bunch of code to ensure that linked services such as mysql were actually up before running code, it might make sense to automate this somehow.

I've been using https://github.com/betalo-sweden/await as a quick helper for this it seems to be a fairly small protocol aware waiter

I have multiple services in my docker-compose.yml with the same image: property. Only one of them has a build: property:

    services:
      app:
        image: my_company/app
        build: .
        ...
      test:
        image: my_company/app

If I just pre-build app then when I try to run the test service, it rebuilds it in the run step.

If I pre-build app and test as described here then it seems to fail to push test to the registry (ECR) and the run step fails because it can't pull the test image.

This is the log output I get for the build step:

    $ docker-compose -f docker-compose.yml -p buildkite12345678908243a0af4110f50924cb4e -f docker-compose.buildkite-488-override.yml push app test
    Pushing app (1234567890.dkr.ecr.ap-southeast-2.amazonaws.com/ape-ci/my_companyweb:my_companyweb-app-build-488)...
    The push refers to a repository [1234567890.dkr.ecr.ap-southeast-2.amazonaws.com/ape-ci/my_companyweb]
    0662cafed00d: Pushed
    f9afaae22bee: Pushed
    27d6313d90dc: Layer already exists
    ...
    bee4f8ad5631: Layer already exists
    cafed00d0415: Layer already exists
    deadbeefbcf9: Layer already exists
    my_companyweb-app-build-488: digest: sha256:8c61d757b9c74eca29d9aa74576fafd6ef8581f5e079af3e00f7a24423832138 size: 4098
    $ buildkite-agent meta-data set docker-compose-plugin-built-image-tag-app 1234567890.dkr.ecr.ap-southeast-2.amazonaws.com/ape-ci/my_companyweb:my_companyweb-app-build-488
    $ buildkite-agent meta-data set docker-compose-plugin-built-image-tag-test 1234567890.dkr.ecr.ap-southeast-2.amazonaws.com/ape-ci/my_companyweb:my_companyweb-test-build-488

Which to me looks like it's asking for test and app to be pushed but it's only pushing app.

Any idea how I can avoid having my run step rebuild my image?

Thanks

Here's the raw log:

~~~ Setting up plugins
�[90m# Could not aquire lock on "/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin.lock" (Locked by other process)�[0m
�[90m# Trying again in 1 second...�[0m
�[90m# Could not aquire lock on "/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin.lock" (Locked by other process)�[0m
�[90m# Trying again in 1 second...�[0m
�[31m🚨 Buildkite Error: open /var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin.lock: no such file or directory�[0m
^^^ +++

And here are the details of the agent:

aws:ami-id=ami-f9d809ef aws:instance-id=i-08e499a4ba6771846 aws:instance-type=c4.xlarge buildkite-aws-stack=v2.0.0-rc5-2-g2f723b2 docker=1.13.1 queue=default stack=buildkite-ci-agents

I believe a bunch of jobs started on this node at the same time. I also noticed that one of the other jobs on the same node failed with this error:

Since cache-from support was added in #82 you can no longer use this plugin on OSX’s default Bash, which is version 3.2, because of the addition of declare -A.

Perhaps we could remove the use of declare -A?

Currently if I create a pre-command or post-command it runs outside of my docker container. Given that my test environment sits within docker, i would rather by default the hooks was run within the context of the same docker container my tests will run in. This will give me the chance to run setup tasks like installing assets and post command like caching assets for the next build.

thx.

v1.8.3 and up of the plugin throw a strange error relating to Docker Compose versions.
There is no issue with v1.8.2 of this plugin.

Agent Version: v3.0-beta.39
Docker version: 17.12.1-ce
Docker Compose version: 1.19.0

Error Message:

/etc/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin-v1-8-4/hooks/../lib/shared.bash: line 70: ${#config_files[@]:-}: bad substitution
--
  | /etc/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin-v1-8-4/hooks/../lib/shared.bash: line 84: config[0]: unbound variable
  | The 'build' option can only be used with Compose file versions 2.0 and above.
  | For more information on Docker Compose configuration file versions, see:
  | https://docs.docker.com/compose/compose-file/compose-versioning/#versioning

pipeline.yml

steps:
  - name: ":docker: Build"
    agents:
      queue: docker-builder
    plugins:
      docker-compose#v1.8.4:
        build: app
        config:
          - docker-compose.ci.yml

docker-compose.ci.yml

version: '3.4'

services:
  app:
    build:
      context: .

It looks like multiple commands aren't supported:

steps:
  - label: ':hammer: Test'
    command:
      - 'echo COMMAND_1'
      - 'echo COMMAND_2'
    plugins:
      docker-compose:
        run: tests
        config: docker-compose.buildkite.yml

I see that it tries to run: docker-compose -f docker-compose.buildkite.yml -p buildkite82973f2986fe406c9a67a03338bca53e run tests echo COMMAND_1 echo COMMAND_2

And my guess is that https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/hooks/commands/run.sh#L43 passes in $BUILDKITE_COMMAND as an array.

Would it be possible to have that line in run.sh iterate over each item of $BUILDKITE_COMMAND and run then sequentially?

As a workaround, I'm including the repeated step inside the first command (a shell script), but it'd be nice to specify multiple command to re-use e.g. a script that processes xunit.xml output files.

I got a following error with multiple agents in one instance.

agent is v3.0-beta.32.

  | Setting up plugins | 5m 0s
-- | -- | --
  | # Could not aquire lock on "/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin-v1-6-0.lock" (Locked by other process)
  | # Trying again in 1s...
  | # Skipping artifact upload, no checkout
  | 🚨 Error: context deadline exceeded

It appears that docker caching isn't working. To reproduce, scale down your builder stack to 1 host, and then run a docker build step a few times. Steps aren't cached.

https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/hooks/commands/build.sh#L22

Hey there!

I've been wrestling with the best way to handle mounted volumes from the host. When Docker runs as root (id=0), the files it writes to the mounted volume are owned by root. Buildkite fails with a permissions error on any remaining files when it goes to git clean the repo on the next job.

On buildkite-agent@2, I was getting around this with a pre-command hook that ran export UID and then a user: $UID property in my docker-compose.yml file. I noticed that with the plugin, this variable is not exposed to the plugin script and compose treats it as missing.

I'd love to be able to either specify a user through the plugin or ideally instruct the plugin to pass the user ID who executed it.

I haven't thought about an API for this, just wanted to get my thoughts down and see if you'd considered this.

Thanks!

I saw an engineer today who was new to Buildkite have difficulty hooking up all the pieces when creating a pipeline. We can make the experience better for both new and experienced engineers by adding some form of static analysis.

I think there's a lot that we can do here, but as a first step, we could perform validation against the docker-compose file. At a minimum it would be nice to ensure that the service exists within docker-compose that the user is attempting to build/leverage in a build step.

STR

Create a pipeline that references a service not defined in docker-compose.yml (or whichever docker-compose file is leveraged). Example:

steps:
  - name: ':docker: :package:'
    plugins:
      'docker-compose#v1.8.4':
        build: some-invalid-docker-service
        image-repository: my.registry/place
  - wait
  - command: ./bin/test
    plugins:
      'docker-compose#v1.8.4':
        run: some-invalid-docker-service

And an example docker-compose.yml file:

version: '2'
services:
  my-default-service:
    build: .

Current Behavior

You see a big error like 🚨 Error: The plugin github.com/buildkite-plugins/docker-compose-buildkite-plugin#v1.8.4 command hook exited with an error: Error running /bin/bash -c /tmp/buildkite-agent-bootstrap-hook-runner-...: exit status 1

Expected Behavior

You're given an error message which will help you understand and track down the issue better within the default expanded section of the log output.

docker-compose recently introduced the ability to declare an image and a build:

https://docs.docker.com/compose/compose-file/#/image

If the image does not exist, Compose attempts to pull it, unless you have also specified build, in which case it builds it using the specified options and tags it with the specified tag.

So for an example like this:

  accounts: 
    image: my-image/llamas:latest
    build:
      context: .
      dockerfile: ops/Dockerfile
    ports:
      - "9005:9005"
    depends_on:
      - mysql

This doesn't work with https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/hooks/commands/build.sh#L34.

We can roll this all into the one plugin…

steps:
  - agents:
      queue: docker-builder
    plugins:
      toolmantim/docker-compose:
        build-and-push:
          build-container: app

  - waiter

  - command: test.sh
    parallelism: 25
    agents:
      queue: docker-compose
    plugins:
      toolmantim/docker-compose:
        command-container: app

or split it out into two:

steps:
  - agents:
      queue: docker-builder
    plugins:
      toolmantim/docker-compose-builder:
        build-container: app

  - waiter

  - command: test.sh
    parallelism: 25
    agents:
      queue: docker-compose
    plugins:
      toolmantim/docker-compose:
        command-container: app

There'd have to be shared knowledge of what build meta-data key to look for to find the name of the built image… and both agents would need to ensure they have the correct docker credentials. But it'd split up the code, simplify the config, and force us to make image name that docker compose uses a public API (in case you wanted to pre-build the images some other way.

So I'm trying to use this plugin to set up a build then run chain .. and it seems like the recent changes that added the config override on build basically make that step entirely ineffective ..

I don't really understand why it is the way it is .. but its looking like it overrides the config setting an image name .. making it impossible to ever actually build it ..

The related build step is:

steps:
  - name: ":docker: :package:"
    plugins:
      docker-compose:
        build: app

Please document how config option CHECK_LINKED_CONTAINERS (aka env BUILDKITE_PLUGIN_DOCKER_COMPOSE_CHECK_LINKED_CONTAINERS) should be used, as seen in https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/hooks/commands/run.sh#L98

I've tried defining the env var in pipeline.yml (in top-level key env and in steps.command.plugins.docker-compose#v1.8.3.env) but each seemed to have no effect.

https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/hooks/commands/build.sh#L6

A tag name may contain lowercase and uppercase characters, digits, underscores, periods and dashes. A tag name may not start with a period or a dash and may contain a maximum of 128 characters.
Source: https://docs.docker.com/engine/reference/commandline/tag/

BUILDKITE_PROJECT_SLUG = [BUILDKITE_ORGANIZATION_SLUG, BUILDKITE_PIPELINE_SLUG].join('/')

Need to amend to use something like:

BUILDKITE_PLUGIN_DOCKER_COMPOSE_IMAGE_NAME="${BUILDKITE_PLUGIN_DOCKER_COMPOSE_IMAGE_NAME:-${BUILDKITE_ORGANIZATION_SLUG}-${BUILDKITE_PIPELINE_SLUG}-${BUILDKITE_PLUGIN_DOCKER_COMPOSE_BUILD}-build-${BUILDKITE_BUILD_NUMBER}}"

We're currently seeing some flakiness with docker images when both uploading and downloading. It would be great if there was a configuration option to enable exponential backoff retrying.

I'm not sure if you have granular control over a single option, or if all of the docker steps would have to be retried. E.g., I'm pulling a lot of images during a build step and one fails. Would it be possible to retry just that package, or would we need to pull all images again?

Since #87 you can't use this plugin with our default buildkite/agent Docker images because they don't include the command-line calc tool bc.

The Docker images were designed to work with this plugin though, hence why they include the docker and docker-compose clients.

Rather than adding it to the buildkite/agent image, perhaps we can do without using bc?

The docs say that image-name default value is built using BUILDKITE_PLUGIN_DOCKER_COMPOSE_BUILD variable:
https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/#image-name-optional.

Looks like this variable is gone now. Is there a way to get a current service name in image-name when building multiple services in one step?

Since the build always pushes up to a registry and there isn't a way to execute a command after the build I think images should be cleaned up after building since steps are inherently stateless.

It seems like when a job is cancelled, either via manual cancel or though timeout, dependant services (like db, redis, etc), and sometimes the main test process if its stuck, get just left behind on the test hosts (this understandably severely impacts memory availability and such)

Using this plugin and this step:

  - label: build
    commands:
      - python setup.py sdist
      - buildkite-agent artifact upload dist/*.tar.gz
    plugins:
      docker-compose#v1.5.2:
        run: app
        config: docker-compose.buildkite.yml

I expected either two calls to docker-compose or a single call using bash eg:

docker-compose -f docker-compose.buildkite.yml run app bash -c "python setup.py sdist && buildkite-agent artifact upload dist/*.tar.gz"

Instead the command reported by buildkite is:

docker-compose -f docker-compose.buildkite.yml -p buildkited85f2a76afb84b34ba66557c6bd4dc25 run app python setup.py sdist buildkite-agent artifact upload dist/\*.tar.gz

Where the commands are concatenated without any handling.

The latest update seems to cause the docker pull command to look like this:

docker pull $'\E[90m$\E[0m buildkite-agent meta-data get docker-compose-plugin-built-image-tag-web\n123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/my-ecr-repo:my-image'

This seems to be the cause:

plugin_get_build_image_metadata uses plugin_prompt_and_must_run which returns \033[90m$\033[0m along with the actual command

I'm attempting to use this plugin to run a docker-compose pipeline. The application was configured to use docker-compose prior to the experiment with Buildkite. In order to support environment variable interpolation with defaults in the compose file, the application uses the 2.1 format. Unfortunately, it looks like this causes an error similar to the following:

ERROR: Version mismatch: file ./docker-compose.yml specifies version 2.1 but extension file ./docker-compose.buildkite-web-override.yml uses version 2.0

One potential solution is to support an environment variable that specifies the docker-compose version (which itself can default to 2.0 😄 ). I imagine this would make it easier for existing applications with significant compose configurations to get onboard.

Another solution is to add an environment variable by disables the override altogether. This solution might be trickier, since (judging from build.sh), there would be no guarantee that the image is correctly tagged for pushing.

When setting pipeline environment variables it commonly catches me and other people in our company out that these variables are not shared with the container. We can specify them manually in the docker-compose file, but it would be nice if this was done automatically.

From PR #26, the logs are getting tailed and then uploaded after the command/test fails. However the logs that are uploaded do not have any content (zero byte)

This is occurring on a AWS Elastic Environment.

This could be some kind of configuration issue. Not sure what else to add here, let me know need more info

Log generation:

EOF
--
  | $ docker logs --timestamps --tail 500 /buildkited48fb259943147958a42a1b6a87f8dd8_dockerpostgres_1
  | EOF
  | EOF
  | EOF
  | $ docker logs --timestamps --tail 500 /buildkited48fb259943147958a42a1b6a87f8dd8_redis_1
  | EOF
  | EOF

Upload:

2017-10-25 01:02:56 INFO   Found 2 files that match "docker-compose-logs/*.log"
--
  | 2017-10-25 01:02:56 INFO   Creating (0-2)/2 artifacts
  | 2017-10-25 01:02:56 INFO   Uploading artifact e3cd97fc-dc34-4ebc-b583-71e9dd1fac5c docker-compose-logs/buildkited48fb259943147958a42a1b6a87f8dd8_redis_1.log (0 bytes)
  | 2017-10-25 01:02:56 INFO   Uploading artifact c6c4738d-7230-4a34-a2da-cb02b517c6ed docker-compose-logs/buildkited48fb259943147958a42a1b6a87f8dd8_dockerpostgres_1.log (0 bytes)

After the 1.8.3 release attempts to run the docker-compose-buildkite plugin with multiple config strings has been raising this error (formatted for ease-of-reading);

$ docker-compose -f $'docker-compose.yml\ndocker-compose.test.yml' 
  -p buildkiteaaabbcc123123123123 -f docker-compose.buildkite-1430-override.yml 
  run --name buildkiteaaabbcc123123123123_api_build_1430 api bundle exec 
  rake knapsack:rspec

  ERROR: .IOError: [Errno 2] No such file or directory: 
  u'./docker-compose.yml\ndocker-compose.test.yml'

The pipeline step throwing this error looks like this;

  - name: ":rspec: %n"
    command: bundle exec rake knapsack:rspec
    parallelism: 8
    plugins:
      docker-compose:
        run: api
        config:
          - docker-compose.yml
          - docker-compose.test.yml

Have briefly discussed this with some work colleagues and we believe it is a regression introduced in this commit.

My steps roughly end up as build, test and finally push. Is there a way to do this currently with the docker-compose-plugin?

It is not possible to download artifacts when we use this plugin. Consider to add an option to pull down artifacts

The problem:
Services which are spun up with depends_on will not display log output during execution.

We have a docker-compose service list as follows:

version: '2.1'
services:
  my-server:
    build: .
    command: yarn start
    expose:
      - 8080
    ports:
      - "8080:8080"
    network_mode: "host"
    healthcheck:
      test: ["CMD-SHELL", "curl -H \"Accept: text/html\" -f http://localhost:8080 || exit 1"]
      interval: 5s
      timeout: 10s
      retries: 5

  server-healthy:
    build: .
    network_mode: "host"
    depends_on:
      my-server:
        condition: service_healthy

  run-service:
    build: .
    network_mode: "host"
    depends_on:
      - server-healthy
    command: ./test.sh

It seems that this is either not documented, or it's not supported, but right now it seems impossible to get the log output of my-server with this plugin. (Docker-compose eats depends_on service log output by default).

Solution for local development:
Developers can manually view output in another terminal tab, via a command like: docker-compose logs -f my-service

Possible solutions for this plugin:

• One possible solution would be a new configuration option allowing developers to tail docker-compose output of selected services. An example of the pipeline implementation:

  - name: 'run tests'
    command: ./test.sh
    plugins:
      'docker-compose#v1.8.0':
        run: run-service
        logs:
          - my-server
          - my-other-service

• It might also be nice if we could have multiple UI tabs for output of different services in the Buildkite frontend, but that would likely require changes in the frontend product, and is not nearly as important as being able to see the logs in the first place.
• If we can't have background tabs during execution, perhaps running docker-compose logs -f <services> & before the docker-compose run script would be sufficient.

Hey guys,

I am running build kite in kubernetes using docker in docker to run my tests and the docker compose plugin keeps the containers running on a canceled build since they don't stop that quickly.

I made my own script that seeps to have fixed the issue I do the following: docker-compose run --rm app run-specs

That ensures the linked containers die even when a build is canceled.

Would be good to have this added but I am not sure how it fit's in with your strategy

Currently only the service that is being run will be checked for prebuilt images. This means that in a situation where you have a system with dependent images, even if you prebuilt them, they will be rebuilt for run.

For example, if you prebuild nginx and php, and then run nginx (which depends on php), nginx will get pulled down, but php will be rebuilt.

Related to #86.

Using +++ here means builds will have the docker build logs expanded by default. This is usually undesirable as you need to scroll through pages of output before you can see your tests.

Wasn't there some magic for "collapse unless failed", maybe ~~~?

Hi,

I'm attempting to run tests of our whole suite (our clients and servers are in separate repos).

To do this, I've created a parent repo with the other repos as submodules. I've created a pipeline and docker-compose files in the parent repo so that Buildkite can build and run the child project images.

I would like to pre-build the images but find that when it hits the run step, it only pulls the image that I'm running, and then proceeds to rebuild the other images specified in docker-compose.yml.

I had a quick look through the plugin code and found this comment:

We only look for a prebuilt image for the service being run. This means that
any other services that are dependencies that need to be built will be built
on-demand in this step, even if they were prebuilt in an earlier step.

Is this something that's likely to change?

Thanks
Ritchie

Given the following pipeline:

env:
  ECR_REPO: "my_ecr_repo.dkr.ecr.us-east-1.amazonaws.com/repo"

steps:
  - name: ":docker: build web"
    agents:
      queue: builders
    plugins:
      docker-compose-buildkite-plugin#v1.1:
        build: web
        config:
          - docker-compose.yml
          - docker-compose.ci.yml
        image-repository: "${ECR_REPO}"

When this runs, the BUILDKITE_PLUGINS environment variable does not include an image-repository key for the plugin.

Instead, I'm forced to add the literal to the config, like so:

steps:
  - name: ":docker: build web"
    agents:
      queue: builders
    plugins:
      docker-compose-buildkite-plugin#v1.1:
        build: web
        config:
          - docker-compose.yml
          - docker-compose.ci.yml
        image-repository: "my_ecr_repo.dkr.ecr.us-east-1.amazonaws.com/repo"

This is non-ideal because ECR_REPO is referenced in multiple subsequent steps throughout the pipeline. Is there a way to avoid the repetition with environment variables, or am I misunderstanding how the environment variable interpolation works?

A slightly different issue occurs when attempting to use the commit as the image-name. Given the following configuration:

steps:
  - name: ":docker: build web"
    agents:
      queue: builders
    plugins:
      docker-compose-buildkite-plugin#v1.1:
        build: web
        config:
          - docker-compose.yml
          - docker-compose.ci.yml
        image-repository: "my_ecr_repo.dkr.ecr.us-east-1.amazonaws.com/repo"
	image-name: "${BUILDKITE_COMMIT}"

The image that is pushed has a tag of HEAD. It appears that at the time of pushing, HEAD has not been resolved to an actual hash. However, under the environment tab, BUILDKITE_COMMIT does show up as a hash. If I trigger a build with a specific commit, the issue does not occur.

It appears that if you don't configure any push/pull retry config value, and a push or pull fails, it just happens infinitely:

~~~ :docker: Pushing image myimagerepo:latest
$ docker tag myapp myimagerepo:latest
$ docker push myimagerepo:latest
The push refers to a repository [myimagerepo]
06aae5e797d6: Preparing
c915c11d0b10: Preparing
a5ea162f0dad: Preparing
6b34e9cb00a8: Preparing
e81b64dfd998: Preparing
ab90d83fa34a: Preparing
8ee318e54723: Preparing
e6695624484e: Waiting
da59b99bbd3b: Waiting
5616a6292c16: Waiting
f3ed6cb59ab0: Waiting
654f45ecb7e3: Waiting
2c40c66f7667: Waiting
no basic auth credentials
Exited with 1
Retrying -1 more times...
$ docker push myimagerepo:latest
The push refers to a repository [myimagerepo]
06aae5e797d6: Preparing
c915c11d0b10: Preparing
a5ea162f0dad: Preparing
6b34e9cb00a8: Preparing
e81b64dfd998: Preparing
ab90d83fa34a: Waiting
8ee318e54723: Waiting
e6695624484e: Waiting
da59b99bbd3b: Waiting
5616a6292c16: Waiting
f3ed6cb59ab0: Waiting
654f45ecb7e3: Waiting
2c40c66f7667: Waiting
no basic auth credentials
Exited with 1
Retrying -2 more times...
$ docker push myimagerepo:latest
The push refers to a repository [myimagerepo]
06aae5e797d6: Preparing
...

I don't think it handles the default value of "0" correctly in the retry logic.

If you have the same service name in two different docker-compose config files, and try to pre-build them for later steps, only the last completed step will be used.

For example, given the following pipeline both of the test commands will run against the prod image, instead of running against their respective images:

steps:
  - name: ":docker:"
    plugins:
      docker-compose#v1.8.4:
        build: app
        image-repository: org/app-dev

  - label: ":docker::zap:"
    plugins:
      docker-compose#v1.8.4:
        config: docker-compose.prod.yml
        build: app
        image-repository: org/app-prod

  - wait

  - label: ":hammer:"
    command: make test
    plugins:
      docker-compose#v1.8.4:
        run: app

  - label: ":hammer::zap:"
    command: make test
    plugins:
      docker-compose#v1.8.4:
        config: docker-compose.prod.yml
        run: app

Perhaps the meta-data key we use to the store the image name should be scoped to the the docker-compose config file as well, and not just the service name?

Hey,

I'm running the Elastic stack at the moment and I haven't re-provisioned it in months so literally nothing has changed in my configuration that I'm aware of.

However, starting this week, more than half of build steps don't use the pre-built image and instead start building their own, which shows as increased buildtime (8m -> 30m in my case, due to having more steps than agents in the project):

Any idea how I can debug this change? The only thing I can think is that my elastic stack is using different versions of the plugin when agent boxes spin down and come back up the next day. The actual base EC2 images shouldn't be changing though as I'm using the same Elastic stack I have been for months.

Is there any info I can give to try to get to the root cause of this?

It seems this pr introduced a bug that breaks the plugin's hook.

Here's a failing build for buildkite staff if you need to inspect: https://buildkite.com/geckoboard/gecko-chef/builds/292#dfc2a011-7800-4b0a-8e72-106f660f426e

~~~ Setting up plugins
�[90m# Plugin "github.com/buildkite-plugins/docker-compose-buildkite-plugin" found�[0m
~~~ Running global environment hook
�[90m# Executing "/etc/buildkite-agent/hooks/environment"�[0m
~~~ Setting up the environment

Sourcing CloudFormation environment...

Starting an SSH Agent...

Agent pid 20257



~~~ Downloading secrets from geckoboard-ci-buildkite-secrets

Downloading ssh-key private_ssh_key

Identity added: /dev/fd/63 (/dev/fd/63)

~~~ Downloading env files

Waiting for Docker...

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES



Fixing permissions for 'buildkite-ci-agents-i-0fe5764ad0f34f302-3'...



~~~ Applying environment changes
�[90m# AWS_ECR_LOGIN changed�[0m
�[90m# AWS_DEFAULT_REGION changed�[0m
�[90m# SSH_AGENT_PID changed�[0m
�[90m# SSH_AUTH_SOCK changed�[0m
�[90m# AWS_REGION changed�[0m
~~~ Preparing build directory
�[90m# Changing working directory to "/var/lib/buildkite-agent/builds/buildkite-ci-agents-i-0fe5764ad0f34f302-3/geckoboard/gecko-chef"�[0m
�[90m# Host "github.com" already in list of known hosts at "/var/lib/buildkite-agent/.ssh/known_hosts"�[0m
�[90m$�[0m git remote set-url origin [email protected]:geckoboard/gecko-chef.git
�[90m$�[0m git clean -fxdq
�[90m$�[0m git submodule foreach --recursive git clean -fxdq
...
�[90m# Fetch and checkout pull request head�[0m
�[90m$�[0m git fetch -v origin refs/pull/771/head
From github.com:geckoboard/gecko-chef
 * branch            refs/pull/771/head -> FETCH_HEAD
�[90m$�[0m git checkout -f 71b7f563c30a3025977b7a5913bdf4af195f4542
HEAD is now at 71b7f56... Add a PostgreSQL data bag for staging
�[90m$�[0m git submodule sync --recursive
....
�[90m$�[0m git submodule update --init --recursive --force
....
�[90m$�[0m git submodule foreach --recursive git reset --hard
....
�[90m# Checking to see if Git data needs to be sent to Buildkite�[0m
�[90m$�[0m buildkite-agent meta-data exists buildkite:git:commit
~~~ Running global pre-command hook
�[90m# Executing "/etc/buildkite-agent/hooks/pre-command"�[0m
~~~ Authenticating with AWS ECR

Flag --email has been deprecated, will be removed in 1.14.

Login Succeeded

~~~ Running plugin github.com/buildkite-plugins/docker-compose-buildkite-plugin command hook
�[90m# Executing "/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin/hooks/command"�[0m
�[90m$�[0m buildkite-agent meta-data get docker-compose-plugin-built-image-tag-0

�[90m$�[0m buildkite-agent meta-data get docker-compose-plugin-built-image-tag-1

2017-04-26 14:25:32 WARN   POST https://agent.buildkite.com/v3/jobs/dfc2a011-7800-4b0a-8e72-106f660f426e/data/get: 404 No key "docker-compose-plugin-built-image-tag-1" found (Attempt 1/10 Retrying in 5s)

2017-04-26 14:25:32 FATAL  Failed to get meta-data: POST https://agent.buildkite.com/v3/jobs/dfc2a011-7800-4b0a-8e72-106f660f426e/data/get: 404 No key "docker-compose-plugin-built-image-tag-1" found

~~~ :docker: Creating a modified docker-compose config for pre-built images

/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin/hooks/../lib/shared.bash: line 123: $2: unbound variable

version: '2'

services:

  681925248577.dkr.ecr.us-east-1.amazonaws.com/buildkite-job-environments:gecko-chef-ci-build-292:

~~~ :docker: Cleaning up after docker-compose

�[90m$�[0m docker-compose -f docker-compose.yml -p buildkitedfc2a01178004b0a8e72106f660f426e kill

�[0m�[90m$�[0m docker-compose -f docker-compose.yml -p buildkitedfc2a01178004b0a8e72106f660f426e rm --force -v

No stopped containers

�[0m�[90m$�[0m docker-compose -f docker-compose.yml -p buildkitedfc2a01178004b0a8e72106f660f426e down --volumes

Removing network buildkitedfc2a01178004b0a8e72106f660f426e_default

�[33mWARNING�[0m: Network buildkitedfc2a01178004b0a8e72106f660f426e_default not found.

�[0m^^^ +++
~~~ Running global post-command hook
�[90m# Executing "/etc/buildkite-agent/hooks/post-command"�[0m
unset SSH_AUTH_SOCK;

unset SSH_AGENT_PID;

echo Agent pid 20257 killed;

~~~ Uploading artifacts
�[90m$�[0m buildkite-agent artifact upload .kitchen/**/* 
�[1;32m2017-04-26 14:25:33 INFO  �[0m �[0mNo files matched paths: .kitchen/**/*�[0m

I have a JSON file that's stored in a Kubernetes secret that's shared with my the Buildagent with the following config.

- mountPath: /root/docker.json
          name: docker-login
          subPath: docker.json

The file is a JSON key for a Kubernetes service account, so obviously not wanting to bake it into any of my images.

I'm using the file within a script to build/push an image using docker push as follows and this works fine.

docker login -u _json_key -p "$(cat /root/docker.json)" https://eu.gcr.io

But I have a docker compose step using this plugin where I load up a pre-built image that contains Gcloud and Kubectl so I can update the deployment to the latest build version, and I need this key file to be able to login, but I can't seem to get the volume to mount with my docker compose file, I'm using the following.

volumes:
      - /root/docker.json:/base/kube/docker.json

But it always throws and error about not being able to create the folder, so seems the docker-compose plugin is not able to see/access the mounted file.

Error response from daemon: error while creating mount source path '/root/docker.json': mkdir /root/docker.json: read-only file system

Not sure how to resolve this?

Having a build step without an image-repository step doesn't make a lot of sense. Based on discussion with @toolmantim it sounds like we should:

• Deprecate build
• Add a prebuild step that is what build was, but with image-repository mandatory
• Clarify in the docs how it should be used

I'm new to docker and buildkite's docker compose plugin so I was a bit confused as to why the environment variables that were showing up in the "Environment" tabs in my builds weren't available within the containers. Eventually I realised I need to explicitly whitelist them in the docker-compose.yml config, e.g.

services:
  my_container:
    environment:
      - BUILDKITE_BUILD_NUMBER
      - BUILDKITE_PROJECT_SLUG
      - ANOTHER_VAR_I_DEFINED_IN_PIPELINE.YML

It'd be nice if these variables were injected by default, so that the experience lines up with what the UI is suggesting will happen.

I find myself often writing scripts for calling docker-compose that pull the image from a previous build step. I'd love a way to automate some of the boiler plate of those. This is an example:

#!/bin/bash
set -eu

cleanup() {
  docker-compose kill || true
  docker-compose rm --force -v || true
  docker-compose down -v || true
}

trap cleanup EXIT

image_name=$(buildkite-agent meta-data get docker-compose-plugin-built-image-tag-blah)

export COMPOSE_PROJECT_NAME="buildkite$$" 
docker pull "$image_name"

... do docker-compose stuff

What if this could be:

steps:
  - command: test.sh
    plugins:
      docker-compose:
        script: my_custom_compose_script.sh

and the script could just be the docker-compose bits? Possibly even with a docker-compose-with-config function that calls the config files from the config.

Would save much pain, and allows extending on the plugin functionality without losing all of the nice bits.

I ran into this issue with 1.2.0.

Running plugin github.com/buildkite-plugins/docker-compose-buildkite-plugin#v1.7.0 command hook | 0s
-- | --
  | # A hook runner was written to "/tmp/buildkite-agent-bootstrap-hook-runner-550291113" with the following:
  | /var/buildkite-agent/plugins/github-com-buildkite-plugins-docker-compose-buildkite-plugin-v1-7-0/hooks/command
  | # Executing "/tmp/buildkite-agent-bootstrap-hook-runner-550291113"
  | $ /bin/bash -c /tmp/buildkite-agent-bootstrap-hook-runner-550291113
  | $ docker-compose -f docker-compose.yml -p buildkitedca524ae891d484094422bf9f196331f config
  | No such command: config
  |  
  | Commands:
  | build     Build or rebuild services
  | help      Get help on a command
  | kill      Kill containers
  | logs      View output from containers
  | port      Print the public port for a port binding
  | ps        List containers
  | pull      Pulls service images
  | rm        Remove stopped containers
  | run       Run a one-off command
  | scale     Set number of containers for a service
  | start     Start services
  | stop      Stop services
  | restart   Restart services
  | up        Create and start containers
  | $ buildkite-agent meta-data get docker-compose-plugin-built-image-tag-statusbot

Should this plugin clear out it's docker tags once done? ECR has a 1000 image limit and this will result in hitting it quickly.

The code that parses the docker-compose file version

It also lacks any sort of fallback or error message if it fails to find a version number.

Imagine a service with containerA and containerB, both need to be built and might have existing imagenames. If you run containerA, it will have an overlayed image name created for it. containerB will not, so it might be stale for a given build.

We would like to build multiple services through docker-compose across machines to parallelize build time.

Given a pipeline like the following we would expect service 1 and service 2 to be built in parallel. I believe today we can build them, but for some reason further steps will be unable to download the first service and they will be built locally.

- name: "SERVICE 1"
  plugins:
    docker-compose:
      build: service1
      image-repository: <repo>
      config: service1/docker-compose.yml
- name: "SERVICE 2"
  plugins:
    docker-compose:
      build: service2
      image-repository: <repo>
      config: service2/docker-compose.yml
- wait
- name: "1st service script"
  command: "ci/script"
  plugins:
    docker-compose:
      run: service1
      config: webapp/docker-compose.yml
- name: "2nd service script"
  command: "ci/script"
  plugins:
    docker-compose:
      run: service2
      config: service2/docker-compose.yml