A Buildkite plugin that lets you build, run and push build steps using Docker Compose.
- Containers are built, run and linked on demand using Docker Compose
- Containers are namespaced to each build job, and cleaned up after use
- Supports pre-building of images, allowing for fast parallel builds across distributed agents
- Supports pushing tagged images to a repository
You can learn a lot about how this plugin is used by browsing the documentation examples.
You will need to specify at least one of the following to use this extension.
The name of a service to build and store, allowing following pipeline steps to run faster as they won't need to build the image. Either a single service or multiple services can be provided as an array.
If you do not specify a push option for the same services, the built image(s) will not be available to be used and may cause further steps to fail. If there is no run option, the step's command will be ignored.
The name of the service the command should be run within. If the docker-compose command would usually be docker-compose run app test.sh then the value would be app.
A list of services to push. You can specify just the service name to push or the format service:registry:tag to override where the service's image is pushed to. Needless to say, the image for the service must have been built in the very same step or built and pushed previously to ensure it is available for pushing.
None of the following are mandatory.
Pull down multiple pre-built images. By default only the service that is being run will be pulled down, but this allows multiple images to be specified to handle prebuilt dependent images. Note that pulling will be skipped if the skip-pull option is activated.
Whether to collapse or expand the log group that is created for the output of the main commands (run, build and push). When this setting is true, the output is collected into a --- group, when false the output is collected into a +++ group. Setting this to true can be useful to de-emphasize plugin output if your command creates its own +++ group.
For more information see Managing log output.
Default false
The file name of the Docker Compose configuration file to use. Can also be a list of filenames. If $COMPOSE_FILE is set, it will be used if config is not specified.
Default: docker-compose.yml
Other docker-compose services that should be aliased to the service that was built. This is to have a pre-built image set for different services based off a single definition.
Important: this only works when building a single service, an error will be generated otherwise.
A list of KEY=VALUE that are passed through as build arguments when image is being built.
A list of either KEY or KEY=VALUE that are passed through as environment variables to the container.
If you set this to VALUE, and VALUE is an environment variable containing a space-separated list of environment variables such as A B C D, then A, B, C, and D will all be propagated to the container. This is helpful when you've set up an environment hook to export secrets as environment variables, and you'd also like to programmatically ensure that secrets get propagated to containers, instead of listing them all out.
Whether or not to automatically propagate all pipeline environment variables into the run container. Avoiding the need to be specified with environment.
Important: only pipeline environment variables will be propagated (what you see in the BuildKite UI, those listed in $BUILDKITE_ENV_FILE). This does not include variables exported in preceeding environment hooks. If you wish for those to be propagated you will need to list them specifically or use env-propagation-list.
Whether or not to automatically propagate aws authentication environment variables into the docker container. Avoiding the need to be specified with environment. This is useful for example if you are using an assume role plugin or you want to pass the role of an agent running in ECS or EKS to the docker container.
Will propagate AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION, AWS_DEFAULT_REGION, AWS_STS_REGIONAL_ENDPOINTS, AWS_WEB_IDENTITY_TOKEN_FILE, AWS_ROLE_ARN, AWS_CONTAINER_CREDENTIALS_FULL_URI, AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, and AWS_CONTAINER_AUTHORIZATION_TOKEN, only if they are set already.
When the AWS_WEB_IDENTITY_TOKEN_FILE is specified, it will also mount it automatically for you and make it usable within the container.
Sets the command for the Docker image, and defaults the shell option to false. Useful if the Docker image has an entrypoint, or doesn't contain a shell.
This option can't be used if your step already has a top-level, non-plugin command option present.
Examples: [ "/bin/mycommand", "-c", "test" ], ["arg1", "arg2"]
Set the shell to use for the command. Set it to false to pass the command directly to the docker-compose run command. The default is ["/bin/sh", "-e", "-c"] unless you have provided a command.
Example: [ "powershell", "-Command" ]
Whether to skip the repository checkout phase. This is useful for steps that use a pre-built image and will fail if there is no pre-built image.
Important: as the code repository will not be available in the step, you need to ensure that any files used (like the docker compose files or scripts to be executed) are present in some other way (like using artifacts or pre-baked into the images used).
Completely avoid running any pull command. Images being used will need to be present in the machine from before or have been built in the same step. Could be useful to avoid hitting rate limits when you can be sure the operation is unnecessary. Note that it is possible other commands run in the plugin's lifecycle will trigger a pull of necessary images.
Specify the container working directory via docker-compose run --workdir. This option is also used by mount-checkout if it doesn't specify where to mount the checkout in the container.
Example: /app
Run as specified username or uid via docker-compose run --user.
Whether to match the user ID and group ID for the container user to the user ID and group ID for the host user. It is similar to specifying user: 1000:1000, except it avoids hardcoding a particular user/group ID.
Using this option ensures that any files created on shared mounts from within the container will be accessible to the host user. It is otherwise common to accidentally create root-owned files that Buildkite will be unable to remove, since containers by default run as the root user.
Whether to mount the ssh-agent socket (at /ssh-agent) from the host agent machine into the container or not. Instead of just true or false, you can specify absolute path in the container for the home directory of the user used to run on which the agent's .ssh/known_hosts will be mounted (by default, /root).
Default: false
Whether to automatically mount the buildkite-agent binary and associated environment variables from the host agent machine into the container.
Default: false
The absolute path where to mount the current working directory which contains your checked out codebase.
If set to true it will mount onto /workdir, unless workdir is set, in which case that will be used.
Default: false
A number of times to retry failed docker pull. Defaults to 0.
A number of times to retry failed docker push. Defaults to 0.
A list of images to attempt pulling before building in the format service:CACHE-SPEC to allow for layer re-use. Will be ignored if no-cache is turned on.
They will be mapped directly to cache-from elements in the build according to the spec so any valid format there should be allowed.
Allow for intermediate builds as if building with docker's --target VALUE options.
Note that there is a single build command run for all services so the target value will apply to all of them.
A list of volumes to mount into the container. If a matching volume exists in the Docker Compose config file, this option will override that definition.
Additionally, volumes may be specified via the agent environment variable BUILDKITE_DOCKER_DEFAULT_VOLUMES, a ; (semicolon) delimited list of mounts in the -v syntax. (Ex. buildkite:/buildkite;./app:/app).
When set to true, it will activate interpolation of variables in the elements of the volumes configuration array. When turned off (the default), attempting to use variables will fail as the literal $VARIABLE_NAME string will be passed to the -v option.
eval which could lead to arbitrary code execution or information leaking if you don't have complete control of the pipeline
Note that rules regarding environment variable interpolation apply here. That means that $VARIABLE_NAME is resolved at pipeline upload time, whereas $$VARIABLE_NAME will be at run time. All things being equal, you likely want to use $$VARIABLE_NAME on the variables mentioned in this option.
Gracefully shuts down all containers via 'docker-compose stop`.
The default is false.
Prevent the removal of volumes after the command has been run.
The default is false.
Build with --no-cache, causing Docker Compose to not use any caches when building the image. This will also avoid creating an override with any cache-from entries.
The default is false.
Build with --parallel, causing Docker Compose to run builds in parallel. Requires docker-compose 1.23+.
The default is false.
If set to true, allocates a TTY. This is useful in some situations TTYs are required.
The default is false.
If set to false, runs with --no-deps and doesn't start linked services.
The default is true.
If dependencies are activated (which is the default), you can skip starting them up before the main container by setting this option to false. This is useful if you want compose to take care of that on its own at the expense of messier output in the run step.
Whether to wait for dependencies to be up (and healthy if possible) when starting them up. It translates to using [--wait in the docker-compose up] command.
Defaults to false.
If set to false, disables the ansi output from containers.
The default is true.
If set to true, docker compose will use the service's network aliases in the network(s) the container connects to.
The default is false.
Sets docker-compose to run with --verbose
The default is false.
Start up dependencies with --quiet-pull to prevent even more logs during that portion of the execution.
The default is false.
If set to true, docker compose will remove the primary container after run. Equivalent to --rm in docker-compose.
The default is true.
If set to true, adds useful Docker labels to the primary container. See Container Labels for more info.
The default is true.
If set to true, all docker compose commands will rum with compatibility mode. Equivalent to --compatibility in docker compose.
The default is false.
Note that the effect of this option changes depending on your docker compose CLI version:
- in v1 it translates (composefile) v3 deploy keys to their non-swarm (composefile) v2 equivalents
- in v2 it will revert some behaviour to v1 as well, including (but not limited to):
Sets the --entrypoint argument when running docker compose.
If set to true, docker compose will run with the service ports enabled and mapped to the host. Equivalent to --service-ports in docker-compose.
The default is false.
Select when to upload container logs.
on-errorUpload logs for all containers when an error occursalwaysAlways upload logs for all containerneverNever upload logs for all container
The default is on-error.
If set to 1, plugin will use docker-compose (that is deprecated and unsupported) to execute commands; otherwise it will default to version 2, using docker compose instead.
Assuming you have a compatible docker installation and configuration in the agent, activating this option would setup the environment for the docker compose build call to use BuildKit. Note that this should only be necessary if you are using cli-version 1 (version 2 already uses buildkit by default).
You may want to also add BUILDKIT_INLINE_CACHE=1 to your build arguments (args option in this plugin), but know that there are known issues with it.
It will add the --ssh option to the build command with the passed value (if true it will use default). Note that it assumes you have a compatible docker installation and configuration in the agent (meaning you are using BuildKit and it is correctly setup).
All elements in this array will be passed literally to the build command as parameters of the --secrets option. Note that you must have BuildKit enabled for this option to have any effect and special RUN stanzas in your Dockerfile to actually make use of them.
To run the tests:
docker-compose run --rm tests bats tests tests/v1MIT (see LICENSE)