Build and Push an image to Docker Registry
This topic describes settings for the Build and Push an image to Docker Registry step, which creates a Docker image from a Dockerfile and pushes it to a Docker registry. For more information, go to Build and push an artifact.
Depending on the stage's build infrastructure, some settings may be unavailable.
Because the Build and Push an image to Docker Registry step is equivalent to the Docker build and push commands, you can use this step or the Build and Push to ACR step to push to Azure Container Registry (ACR).
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.
The Harness Docker Registry connector where you want to upload the image. For more information, go to Docker connector settings reference.
This step supports Docker connectors that use username and password authentication.
The name of the repository where you want to store the image, for example,
For private Docker registries, specify a fully qualified repo name.
Add Docker build tags. This is equivalent to the
Add each tag separately.
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.
Use the following settings to add additional configuration to the step. 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.
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.
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.
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.
Kaniko requires root access to build the Docker image. If you have not already enabled root access, you will receive the following error:
failed to create docker config file: open/kaniko/ .docker/config.json: permission denied
Specify Docker object labels to add metadata to the Docker image.
The Docker build-time variables. This is equivalent to the
The Docker target build stage, equivalent to the
--target flag, such as
Remote Cache Image
Enter the name of the remote cache image, such as
The remote cache repository must exist in the same host and project as the build image. The repository will be automatically created if it doesn't exist. For caching to work, the entered 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 subsequent 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
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.
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
M. You can also use the power-of-two equivalents
Mi. The default is
- 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
100m. The default is
400m. For more information, go to Resource units in Kubernetes.
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: