Build step

Building Docker images in Codefresh pipelines

Use Docker to build an image and store it in Codefresh or push it to an external registry. Create multi-platform images with BuildX and QEMU (Quick EMUlator).
In Codefresh, Docker containers are first-class citizens, and we offer special typed steps for the most frequently used Docker commands through our build step.

Purpose of build steps

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

is converted in Codefresh into the following build step:

BuildMyImage:
  title: Building My Docker image
  type: build
  image_name: my-app-image
  tag: 1.0.1

Usage

YAML

step_name:
  type: build
  title: Step Title
  description: Free text description
  working_directory: ${{clone_step_name}}
  dockerfile: path/to/Dockerfile
  image_name: owner/new-image-name
  tag: develop
  platform: 'linux/arm64'
  buildx: true
  build_arguments:
    - key=value
  cache_from:
    - owner/image-name:$
    - owner/image-name:main
  target: stage1
  no_cache: false
  no_cf_cache: false
  tag_policy: original
  fail_fast: false
  metadata:
    set:
      - qa: pending
  when:
    condition:
      all:
        noDetectedSkipCI: "includes('${{CF_COMMIT_MESSAGE}}', '[skip ci]') == false"
  on_success:
    ...
  on_fail:
    ...
  on_finish:
    ...
  retry:
    ...

Fields

Field Description Required/Optional/Default
title The free-text display name of the step. Optional
description A basic, free-text description of the step. Optional
stage Parent group of this step. For more information, see Stages in pipelines. Optional
working_directory 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 ${{main_clone}} . Note that the working_directory when defined changes only the Docker build context. It is unrelated to the WORKDIR in the Dockerile.
Default
dockerfile The path to the Dockerfile from which the image is built. The default is Dockerfile. Default
image_name The name of the image that is built. Required
region Relevant only for Amazon ECR integrations using either service accounts or explicit credentials. The names of the regions for which to perform cross-region replication. The names of the source region and the destination region name must be defined in separate steps. Optional
tag The single tag to assign to the built image. To assign multiple tags, use tags (see below).
The default tag is the name of the branch or revision that is built.
Default
tags Multiple tags to assign to the built image.
To assign a single tag, use tag (see above).
This is an array, and should conform to the following syntax:
tags:
- tag1
- tag2
- ${{CF_BRANCH_TAG_NORMALIZED}}
- tag4


OR
tags: [ 'tag1', 'tag2', '${{CF_BRANCH_TAG_NORMALIZED}}', 'tag4' ]
Optional
cache_from The list of cache sources to use as Docker cache when building the image. Every source in the list is passed to the build command using the --cache-from flag. See Docker documentation for more info. Optional
registry The name of the registry to which to push the built image. You can define any registry that is integrated with Codefresh.
When not defined, and you have multiple registry contexts, Codefresh uses the one set as the default registry.
Optional
registry_contexts Advanced property for resolving Docker images when working with multiple registries with the same domain. When defined, pulls the image from the specified context.
NOTE: When using buildx to build and push multi-platform images, registry_contexts cannot be assigned a different registry from the same domain as the target registry defined for registry, as Docker does not support being logged in to multiple Docker registries that share the same domain at the same time.
Optional
disable_push Defines if to automatically push the built image to the registry or not. When set to false, the default, the image is automatically pushed to the registry.

NOTE: Because of Docker’s limitation on loading multi-platform images to the local Docker instance, unless the built image is pushed as part of the build step, you cannot reference the same image in subsequent steps using the ${{build_step_name}} variable.
Optional
tag_policy The case-transformation policy for the tag name.
originalpushes the tag name as is, without changing it.
lowercase, the default, automatically converts the tag name to lowercase.

Tags in mixed case are pushed as image_name:<tagname> when set to the default value.
Default
no_cache Defines if to enable or disable Docker engine cache for the build. When set to false, the default, enables Docker engine cache. To disable, set to true. See more info. Optional
no_cf_cache Defines if to enable or disable Codefresh build optimization for the build. When set to false, the default, enables Codefresh build optimization. See more info.  
build_arguments The set of Docker build arguments to pass to the build process. Optional
target The target stage at which to stop the build in a multistage build. Optional
timeout The maximum duration permitted to complete step execution in seconds (s), minutes (m), or hours (h), after which to automatically terminate step execution. For example, timeout: 1.5h.
The timeout supports integers and floating numbers, and can be set to a maximum of 2147483647ms (approximately 24.8 days).

If defined and set to either 0s/m/h or null, the timeout is ignored and step execution is not terminated.
See Add a timeout to terminate step execution.
Optional
fail_fast Define the build behavior on step failure. When set to true, the default, ff a step fails, the build is stopped as well. To continue the build on step failure, set to false. Default
when The set of conditions that need to be satisfied in order to execute this step.
For more information, see Conditional execution of steps .
Optional
metadata Annotate the built image with key-value metadata. Optional
on_success, on_fail and on_finish Define operations to perform upon step completion using a set of predefined Post-step operations. Optional
retry Define retry behavior for the build step, as described in Retrying a step. Optional
buildkit When set to true, enables Buildkit and all of its enhancements. When using buildkit with cache_from, to allow the built image to be used as cache for future images, you must specify BUILDKIT_INLINE_CACHE=1 in the build_arguments. See more info Optional
ssh Available when using Buildkit for ssh keys. See more info Optional
secrets Available when using Buildkit for secret mounting. See more info Optional
platform The target platform or platforms to which to push the image. For example, linux/amd64. To target multiple platforms, separate them with commas, as in linux/amd64,linux/arm64.
NOTE: To use this property, you must enable buildx.
Optional
buildx Build and push Docker images, including multi-platform images, with Buildx. Disabled by default.
  • To enable with default configuration, set to true. You do not have to add any other parameters.
  • To enable with custom configuration, set to an object with custom configuration. With custom configuration, you can configure settings for qemu and builder.
    • qemu
      • image: The Docker image to use to install the QEMU static binaries. Currently, Codefresh supports the tonistiigi/binfmt Docker image.
        By default, installs the binaries from the tonistiigi/binfmt:latest Docker image.
      • platforms: The binaries of platform emulators to install with the Docker image defined for image. The default value is all.
    • builder:
      • driver: The builder driver to use. By default, uses docker-container driver to build multi-platform images and export cache using a BuildKit container.
      • driver_opts: Additional driver-specific configuration options to customize the driver. For example, image=moby/buildkit:master.
Optional

Exported resources

Build image step examples

Add a timeout to terminate step execution

To prevent steps from running beyond a specific duration if so required, you can add the timeout flag to the step.
When defined:

  • The timeout is activated at the beginning of the step, before the step pulls images.
  • When the step’s execution duration exceeds the duration defined for the timeout, the step is automatically terminated.

NOTE:
To define timeouts for parallel steps, see Adding timeouts for parallel steps.

Here’s an example of the timeout field in the step:

YAML

step_name:
  type: build
  title: Step Title
  description: Free text description
  working_directory: ${{clone_step_name}}
  dockerfile: path/to/Dockerfile
  image_name: owner/new-image-name
  tag: develop
  platform: 'linux/arm64'
  buildx: true
  build_arguments:
    - key=value
  cache_from:
    - owner/image-name:$
    - owner/image-name:main
  target: stage1
  no_cache: false
  no_cf_cache: false
  tag_policy: original
  timeout: 45m
  fail_fast: false
  metadata:
    set:
      - qa: pending
  when:
    condition:
      all:
        noDetectedSkipCI: "includes('${{CF_COMMIT_MESSAGE}}', '[skip ci]') == false"
  on_success:
    ...
  on_fail:
    ...
  on_finish:
    ...
  retry:
    ...

Timeout info in logs
Timeout information is displayed in the logs, as in the example below.

Step termination due to timeout in logs

Step termination due to timeout in logs

Using Dockerfile in root project folder

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build

Using different Dockerfile and specific version tag

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    image_name: my-app-image
    dockerfile: my-custom.Dockerfile
    tag: 1.0.1

Using different Dockerfile and pushing multiple tags to default registry

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    image_name: my-app-image
    dockerfile: my-custom.Dockerfile
    tags:
      - latest
      - ${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}
      - v1.1
        

Automatically push to registry with name my-registry

For information on registries, see Docker registries for pipeline integrations.

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    image_name: my-app-image
    dockerfile: my-custom.Dockerfile
    tag: 1.0.1
    registry: my-registry

Two images in two different folders using Codefresh variables as tags

For information on Codefresh variables, see Variables in pipelines.

codefresh.yml

version: '1.0'
steps:
  BuildNodeImage:
    title: Building My Node app
    type: build    
    image_name: my-department/my-team/my-node-image
    dockerfile: Dockerfile
    working_directory: ./project1
    tag: ${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}
  BuildGoImage:
    title: Building My Go app
    type: build    
    image_name: my-company/my-go-image
    dockerfile: Dockerfile
    working_directory: ./project2
    tag: ${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}
         

Using cache_from with buildkit

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    image_name: my-app-image
    dockerfile: my-custom.Dockerfile
    tag: 1.0.1
    buildkit: true
    build_arguments:
    - BUILDKIT_INLINE_CACHE=1
    cache_from:
    - my-registry/my-app-image:${{CF_BRANCH}}
    - my-registry/my-app-image:master
         

Multi-platform images with platform and buildx

Docker images can support multiple platforms and architectures, meaning that you can create an image once, and reuse the same image on different platforms. Docker automatically selects the image that matches the target OS and architecture.

For more on the architectures supported, see the Docker Official Images README. For more on multi-platform images in Docker, see the official documentation.

Build image for ARM

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    working_directory: '${{clone}}'
    image_name: my-app-image
    tag: latest
    platform: 'linux/arm64'
    buildx: true
         

Build image for multiple platforms

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    working_directory: '${{clone}}'
    image_name: my-app-image
    tag: latest
    platform: 'linux/amd64,linux/arm64'
    buildx: true
         

Build image for multiple platforms with custom buildx configuration

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    type: build
    working_directory: '${{clone}}'
    image_name: my-app-image
    tag: latest
    platform: 'linux/amd64,linux/arm64'
    buildx:
      qemu:
        # image used for installing QEMU static binaries to provide cross-platform emulator support
        image: 'tonistiigi/binfmt:latest' # default
      builder:
        # driver to use to create the builder instance 
        driver: 'docker-container' # default
         

For faster builds, you can also build Docker images in parallel.

Inline Dockerfile

If your project does not already have a Dockerfile, you can also define one within the pipeline:

codefresh.yml

version: '1.0'
steps:
  BuildingDockerImage:
    title: Building Docker Image
    type: build
    image_name: my-own-go-app
    working_directory: ./
    tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
    dockerfile:
      content: |-
       # ---
       # Go Builder Image
       FROM golang:1.8-alpine AS builder
       # set build arguments: GitHub user and repository
       ARG GH_USER
       ARG GH_REPO
       # Create and set working directory
       RUN mkdir -p /go/src/github.com/$GH_USER/$GH_REPO
       # copy file from builder image
       COPY --from=builder /go/src/github.com/$GH_USER/$GH_REPO/dist/myapp
       /usr/bin/myapp
       CMD ["myapp", "--help"]
         

Use this technique only as a last resort. It is better if the Dockerfile exists as an actual file in source control.

Automatic pushing

All images built successfully with the build step are automatically pushed to the default Docker registry defined for your account. This behavior is completely automatic and happens without any extra configuration on your part. To disable this, add the disable_push property set to true to your build step. Remember that if you are using buildx, you cannot set the disable_push property to true.

The push step in Codefresh is optional, and is only needed if you want to push to external Docker registries.

Docker Images pushed automatically

Docker Images pushed automatically

Buildkit support

Codefresh also allows you to use buildkit with all its enhancements and experimental features.

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:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    buildkit: true

Buildkit is also automatically enabled if you use any of its features such as the progress property:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    progress: tty

Possible values for progress are tty and plain.

For secrets, you can either mention them in a single line:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    secrets:
      - id=secret1,src=./my-secret-file1.txt
      - id=secret2,src=./my-secret-file2.txt

or multiple lines:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    secrets:
      - id: secret1
        src: ./my-secret-file1.txt
      - id: secret2
        src: ./my-secret-file2.txt

For the SSH connection you can either use the default:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    ssh: default

or define different keys:

codefresh.yml

version: '1.0'
steps:
  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    ssh:
      - github=~/.ssh/github_rsa
      - bitbucket=~/.ssh/bitbucket_rsa

You might want to use an environment variable to store and retrieve an SSH key. This can be achieved by converting your 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: codefresh.yml

version: '1.0'
steps:
  SetupSshKeys:
    title: Setting up ssh key
    image: alpine:latest
    commands:
      - mkdir /codefresh/volume/keys
      - echo "${SSH_KEY}" | tr  ',' '\n' > /codefresh/volume/keys/github_rsa

  BuildMyImage:
    title: Building My Docker image
    image_name: my-app-image
    type: build
    tag: latest
    ssh:
      - github=/codefresh/volume/keys/github_rsa

You can combine all options (ssh, progress, secrets) in a single build step if desired.

Codefresh YAML for pipeline definitions
Steps in pipelines