Build

Skaffold supports different tools for building images:

Configuration

The build section in the Skaffold configuration file, skaffold.yaml, controls how artifacts are built. To use a specific tool for building artifacts, add the value representing the tool and options for using that tool to the build section.

For detailed per-builder Skaffold Configuration options, see skaffold.yaml References.

Local Build

Local build execution is the default execution context. Skaffold will use your locally-installed build tools (such as Docker, Bazel, Maven or Gradle) to execute the build.

Configuration

To configure the local execution explicitly, add build type local to the build section of skaffold.yaml

build:
  local: {}

The following options can optionally be configured:

Faster builds

There are a few options for achieving faster local builds.

Avoiding pushes

When deploying to a local cluster, Skaffold defaults push to false to speed up builds. The push setting can be set from the command-line with --push.

Parallel builds

The concurrency controls the number of image builds that are run in parallel. Skaffold disables concurrency by default for local builds as several image builder types (custom, jib) may change files on disk and result in side-effects. concurrency can be set to 0 to enable full parallelism, though this may consume significant resources. The concurrency setting can be set from the command-line with the --build-concurrency flag.

When artifacts are built in parallel, the build logs are still printed in sequence to make them easier to read.

Build avoidance with tryImportMissing

tryImportMissing: true causes Skaffold to avoid building an image when the tagged image already exists in the destination. This setting can be useful for images that are expensive to build.

tryImportMissing is disabled by default to avoid the risk from importing a stale image, where the imported image is different from the image that would have been built from the artifact source. tryImportMissing is best used with a tagging policy such as imageDigest or gitCommit’s TreeSha or AbbrevTreeSha variants, where the tag is computed using the artifact’s contents.

In Cluster Build

Skaffold supports building in cluster via Kaniko or Custom Build Script.

Configuration

To configure in-cluster Build, add build type cluster to the build section of skaffold.yaml.

build:
  cluster: {}

The following options can optionally be configured:

Faster builds

Skaffold can build multiple artifacts in parallel, by settings a value higher than 1 to concurrency. For in-cluster builds, the default is to build all the artifacts in parallel. If your cluster is too small, you might want to reduce the concurrency. Setting concurrency to 1 will cause artifacts to be built sequentially.

Remotely on Google Cloud Build

Skaffold supports building remotely with Google Cloud Build.

Google Cloud Build is a Google Cloud Platform service that executes your builds using Google infrastructure. To get started with Google Build, see Cloud Build Quickstart.

Skaffold can automatically connect to Cloud Build, and run your builds with it. After Cloud Build finishes building your artifacts, they will be saved to the specified remote registry, such as Google Container Registry.

Skaffold Google Cloud Build process differs from the gcloud command gcloud builds submit. Skaffold will create a list of dependent files and submit a tar file to GCB. It will then generate a single step cloudbuild.yaml and will start the building process. Skaffold does not honor .gitignore or .gcloudignore exclusions. If you need to ignore files use .dockerignore. Any cloudbuild.yaml found will not be used in the build process.

Configuration

To use Cloud Build, add build type googleCloudBuild to the build section of skaffold.yaml.

build:
  googleCloudBuild: {}

The following options can optionally be configured:

Faster builds

Skaffold can build multiple artifacts in parallel, by settings a value higher than 1 to concurrency. For Google Cloud Build, the default is to build all the artifacts in parallel. If you hit a quota restriction, you might want to reduce the concurrency.

Restrictions

Skaffold currently supports Docker, Jib on Google Cloud Build.

Cross-platform and Multi-platform build support

Skaffold selectively supports building for an architecture that is different than the development machine architecture (cross-platform build) or building for multiple architectures (multiple-platform build). The target platforms for an artifact can be specified in one of the following ways:

• The pipeline’s platforms property in the skaffold.yaml file.

build:
  platforms: ["linux/arm64"]
  artifacts:
    - image: example

• The artifact’s platforms constraints in the skaffold.yaml file. This overrides the value specified in the pipeline’s platforms property.

build:
  artifacts:
    - image: app1
      platforms: ["linux/arm64"]
    - image: app2
      platforms: ["linux/amd64"]

• The CLI flag --platform which overrides the values set in both the previous ways.

skaffold build --platform=linux/arm64,linux/amd64

Additionally, for skaffold dev, skaffold debug and skaffold run commands, where the build output gets deployed immediately, skaffold checks the platform for the kubernetes cluster nodes and attempts to build artifacts for that target platform.

The final list of target platforms need to ultimately be supported by the target builder, otherwise it’ll fail the build. The cross-platform build support for the various builders can be summarized in the following table: