This topic provides settings for the Build and Push to GCR Step, which builds an image and pushes it to GCR.
This step assumes that the target GCR registry meets the GCR requirements for pushing images. See Pushing and pulling images from Google.
The unique name for this Connector.
The Harness GCP Connector to use to connect to GCR. See Google Cloud Platform (GCP) Connector Settings Reference.
The GCR 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
The GCP Resource Manager project ID.
The name of the image you want to build.
Docker build tag (
-t). Add each tag separately.
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 represents a directory containing a Dockerfile that kaniko uses to build your image. For example, a
COPY command in your Dockerfile should refer to a file in the build context.
Docker object labels to add metadata to the Docker image.
The Docker build-time variables (
The Docker target build stage (--target).
Remote Cache Image
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.
This is different from other CI vendors that are limited to local caching and persistent volumes.
You can also specify the same Docker repo for multiple Build and Push steps, enabling them to share the same remote cache.
Remote Docker Layer Caching can dramatically improve build time by sharing layers across Pipelines, Stages, and steps.
Enter the name of the remote cache image (for example,
The Remote Cache Repository must be in the same account and organization as the build image. For caching to work, the entered image name must exist.
Run as User
Set the value to specify the user id for all processes in the pod, running in containers. See Set the security context for a pod.
Set container resources
Maximum resources limit values for the resources used by the container at runtime.
Maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number using the suffixes
M. You can also use the power-of-two equivalents
The maximum number of cores that the container can use. CPU limits are measured in cpu units. Fractional requests are allowed: you can specify one hundred millicpu as
100m. See Resource units in Kubernetes.
Timeout for the step. Once the timeout is reached, the step fails, and the Pipeline execution continues.