Build and Push to ECR Step Settings
This topic provides settings for the Build and Push to ECR step, which builds an image and pushes it to AWS ECR.
See also Pushing a Docker image in the AWS docs.
Name
The unique name for this Connector.
Id
See Entity Identifier Reference.
AWS Connector
The Harness AWS Connector to use to connect to ECR. The AWS IAM roles and policies associated with the account used in the Harness AWS Connector must be able to push to ECR. See AWS Connector Settings Reference.
Region
The AWS region to use when pushing the image. The registry format for ECR is aws_account_id.dkr.ecr.region.amazonaws.com
and a region is required. See Pushing a Docker image from AWS.
Account Id
The AWS account Id to use when pushing the image. The registry format for ECR is aws_account_id.dkr.ecr.region.amazonaws.com
and an account Id is required. See Pushing a Docker image from AWS.
Image Name
The name of the image you are pushing. It can be any name.
Tags
Docker build tag (-t
).
Each tag should added separately.
Optional Configuration
Base Image Connector
Select an authenticated Connector to download base images from the container registry. Otherwise, the Step downloads base images without authentication. Specifying a Base Image Connector is recommended because unauthenticated downloads generally have a lower rate limit than authenticated downloads.
Optimize
Enable this option to redo snapshot mode.
Dockerfile
The name of the Dockerfile. If you don't provide a name, Harness assumes the Dockerfile is in the root folder of the codebase.
Context
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.
Labels
Docker object labels to add metadata to the Docker image.
Build Arguments
The Docker build-time variables (--build-arg
).
Target
The Docker target build stage (--target). For example, build-env
.
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 subsequent 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.
In addition, you can 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, app/myImage
).
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.
Limit Memory
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
.
Limit CPU
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 0.1
or 100m
. See Resource units in Kubernetes.
Timeout
Timeout for the step. Once the timeout is reached, the step fails, and the Pipeline execution continues.