Skip to main content

Build and Push to GCR

This topic explains how to configure the Build and Push to GCR step in a Harness CI pipeline. This step is used to build and push to Google Container Registry (GCR).

Kubernetes cluster build infrastructures

With Kubernetes cluster build infrastructures, Build and Push steps use kaniko. Other build infrastructures use drone-docker. Kaniko requires root access to build the Docker image. It doesn't support non-root users.

If your build runs as non-root (runAsNonRoot: true), and you want to run the Build and Push step as root, you can set Run as User to 0 on the Build and Push step to use the root user for that individual step only.

If your security policy doesn't allow running as root, go to Build and push with non-root users.

Add the Build and Push to GCR step​

Add the Build and Push to GCR step to the Build stage in a CI pipeline If you haven't created a pipeline before, try one of the CI tutorials.

The Build and Push to GCR step settings are described below. Depending on the stage's build infrastructure, some settings may be unavailable or located under Optional Configuration in the visual pipeline editor. Settings specific to containers, such as Set Container Resources, are not applicable when using the step in a stage with VM or Harness Cloud build infrastructure.

Name​

Enter a name summarizing the step's purpose. Harness automatically assigns an Id (Entity Identifier Reference) based on the Name. You can change the Id.

GCP Connector​

The Harness GCP connector to use to connect to GCR. The GCP account associated with the GCP connector needs specific roles. For more information, go to Google Cloud Platform (GCP) connector settings reference.

This step supports GCP connectors that use access key authentication. It does not support GCP connectors that inherit delegate credentials.

Host​

The Google Container Registry hostname. For example, us.gcr.io hosts images in data centers in the United States in a separate storage bucket from images hosted by gcr.io. For a list of Container Registries, go to the Google documentation on Pushing and pulling images.

info

The target GCR registry must meet the GCR requirements for pushing images. For more information, go to the Google documentation on Pushing and pulling images.

Project ID​

The GCP resource manager project ID.

Image Name​

The name of the image you want to build and push to the target container registry.

Tags​

Add Docker build tags. This is equivalent to the -t flag.

Add each tag separately.

tip

Harness expressions are a useful way to define tags. For example, <+pipeline.sequenceId> is a built-in Harness expression. It represents the Build ID number, such as 9. You can use the same tag in another stage to reference the same build by its tag.

Optimize​

With Kubernetes cluster build infrastructures, select this option to enable --snapshotMode=redo. This setting causes file metadata to be considered when creating snapshots, and it can reduce the time it takes to create snapshots. For more information, go to the kaniko documentation for the snapshotMode flag.

Dockerfile​

The name of the Dockerfile. If you don't provide a name, Harness assumes that the Dockerfile is in the root folder of the codebase.

Context​

Enter a path to a directory containing files that make up the build's context. When the pipeline runs, the build process can refer to any files found in the context. For example, a Dockerfile can use a COPY instruction to reference a file in the context.

Labels​

Specify Docker object labels to add metadata to the Docker image.

Build Arguments​

The Docker build-time variables. This is equivalent to the --build-arg flag.

Target​

The Docker target build stage, equivalent to the --target flag, such as build-env.

Remote Cache Image​

Enter the name of the remote cache image, such as gcr.io/project-id/<image>.

The remote cache repository must be in the same account and organization as the build image. For caching to work, the specified image name must exist.

Harness enables remote Docker layer caching where each Docker layer is uploaded as an image to a Docker repo you identify. If the same layer is used in later builds, Harness downloads the layer from the Docker repo. You can also specify the same Docker repo for multiple Build and Push steps, enabling these steps to share the same remote cache. This can dramatically improve build time by sharing layers across pipelines, stages, and steps.

Run as User​

With Kubernetes cluster build infrastructures, you can specify the user ID to use to run all processes in the pod if running in containers. For more information, go to Set the security context for a pod.

This step requires root access. You can use the Run as User setting if your build runs as non-root (runAsNonRoot: true), and you can run the Build and Push step as root. To do this, set Run as User to 0 to use the root user for this individual step only.

If your security policy doesn't allow running as root, go to Build and push with non-root users.

Set container resources​

Set maximum resource limits for the resources used by the container at runtime:

  • Limit Memory: The maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number using the suffixes G or M. You can also use the power-of-two equivalents Gi and Mi. The default is 500Mi.
  • Limit CPU: The maximum number of cores that the container can use. CPU limits are measured in CPU units. Fractional requests are allowed; for example, you can specify one hundred millicpu as 0.1 or 100m. The default is 400m. For more information, go to Resource units in Kubernetes.

Timeout​

Set the timeout limit for the step. Once the timeout limit is reached, the step fails and pipeline execution continues. To set skip conditions or failure handling for steps, go to:

Advanced settings​

You can find the following settings on the Advanced tab in the step settings pane:

Run the pipeline​

After saving the pipeline, select Run to run the pipeline.

On the build details page, you can see the logs for each step as they run.

If the build succeeds, you can find your pushed image on GCR.

See also​