Building Docker images in Codefresh pipelines
Use Docker to build an image and store it in Codefresh.
Purpose of build steps
In Codefresh, docker containers are first-class citizens
and special typed steps are offered for the most usual docker commands. Build steps are a secure replacement for
docker build commands.
Therefore, this command on your local workstation:
docker build . -t my-app-image:1.0.1
will become in Codefresh the following build step.
BuildMyImage: title: Building My Docker image type: build image_name: my-app-image tag: 1.0.1
||The free-text display name of the step.||Optional|
||A basic, free-text description of the step.||Optional|
||Parent group of this step. See using stages for more information.||Optional|
||The directory in which the build command is executed. It can be an explicit path in the container’s file system, or a variable that references another step.
The default is
||The path to the
||The name for the image you build.||Required|
||The tag that is assigned to the image you build.
The default is the name of the branch or revision that is built.
||Disable Docker engine cache for the build more info||Optional|
||Disable Codefresh build optimization for the build more info|
||A set of Docker build arguments to pass to the build process.||Optional|
||target stage in a multistage build (build will run until this stage)||Optional|
||If a step fails, and the process is halted. The default value is
||Define a set of conditions that need to be satisfied in order to execute this step.
You can find more information in the Conditional Execution of Steps article.
||Annotate the built image with key-value metadata.||Optional|
||Define operations to perform upon step completion using a set of predefined Post-Step Operations.||Optional|
||Define retry behavior as described in Retrying a step.||Optional|
- Working Directory
- Image ID
Build an image using a Dockerfile in the root project folder:
Build an image using a different Dockerfile and a specific version tag
Build two images in two different folders using Codefresh variables as tags.
It also possible to build Docker images in parallel for faster builds.
If your project does not already have a Dockerfile, you can also define one within the pipeline:
Use this technique only as a last resort. It is better if the Dockerfile exists as an actual file in source control.
All images built successfully with the build step, will be automatically pushed to the internal Codefresh registry. This behavior is completely automatic and happens without any extra configuration on your part.
Using buildkit you can get:
- Improved build output logs
- Mounting of external secrets that will never be stored in the image
- Access to SSH keys and sockets from within the Dockerfile
- Use cache and bind-mounts at build time
These capabilities are offered as extra arguments in the build step and using any of them will automatically enable buildkit. You can utilize the different mount-options for the Dockerfile instruction
RUN as long as buildkit is enabled for your build step. Mounts of type
cache work out of the box and are persisted between pipeline runs.
The simplest way to use buildkit is by enabling it explicitly:
Buildkit is also automatically enabled if you use any of its features such as the
Possible values for
For secrets you can either mention them in a single line:
or multiple lines:
For the SSH connection you can either use the default:
or define different keys:
You might want to use an environment variable to store and retrieve a ssh key. This can be achieved by converting you ssh key into a one-line string:
tr '\n' ',' < /path/to/id_rsa
Copy the output and place it an environment variable. To make the SSH key availabe to the build step, you can write it to the codefresh volume:
You can combine all options (
secrets) in a single build step if desired.