Build Docker Image - Features, integrations, alternatives & more
What it does
This action builds Docker image using Dockerfile. It’s also possible to use this action to push a built image to a Docker registry.
How it works
The action runs Docker build
command in a context of a pipeline filesystem. If details to a private Docker registry are provided in the action's Options, the connection to the registry is established before the Docker build
command is executed.
Action preview

Docker Build Image Action Features
- Support for pulling and pushing from Docker Hub Private, Amazon ECR, Google GCR and own private registry
- It’s possible to push the built image to all supported Docker registries
- Support for pushing an image with multiple tags (if delivery to a Docker registry is enabled)
- Multi-stage builds
- It’s possible to run built image in the next pipeline steps (Run Docker Image or as a custom service attached to an action)
- Settable context. The docker build command builds Docker images from a Dockerfile and a “context”. A build’s context is a set of files located in the specified path. The build process can refer to any of the files in the context.
- Support for Build arguments: it’s possible to pass arguments on build-time that are accessed, like regular environment variables in the RUN instruction of the Dockerfile. The build arguments support Buddy Params
- By default, the action removes cache layers that are not used anymore. If you want to keep it anyway, use the Don’t prune old layers option
- It’s possible to build up to certain Docker image layer using Target build stage option. When building a Dockerfile with multiple build stages, --target can be used to specify an intermediate build stage by name as a final stage for the resulting image. Commands after the target stage will be skipped.
- The action can be configured in YAML mode. See Build Docker Image YAML parameters and Build Docker Image YAML config example
- Buddy's Build Docker Image API is supported
- The action supports conditional execution: it can be run on each execution, only if there are changes in the repository or specific paths since last execution or if an environment variable has a specific value
- Error handling: you can either stop the execution, mark action and pipeline as failed or proceed the execution, mark action as warning and jump to the next action