Skip to main content

Build and Push to JFrog Docker registries

This topic explains how to use the Build and Push an image to Docker Registry step to build and push an image to JFrog Artifactory Docker registries.

For JFrog non-Docker registries, you can use a script in a Run step to build the artifact, and then use the Upload Artifacts to JFrog step to upload the artifact.

You need:

Kubernetes cluster build infrastructures require root access​

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.

Build and push to JFrog Docker registries​

In your pipeline's Build stage, add a Build and Push an image to Docker Registry step and configure the settings for JFrog.

Here is a YAML example of a Build and Push an image to Docker Registry step configured for JFrog:

              - step:
                  type: BuildAndPushDockerRegistry
                  name: Build and push to JFrog Docker
                  identifier: Build_and_push_to_JFrog_Docker
                  spec:
                    connectorRef: YOUR_DOCKER_CONNECTOR_ID
                    repo: domain.jfrog.io/REPO/IMAGE
                    tags:
                      - <+pipeline.sequenceId>

When you run a pipeline, you can observe the step logs on the build details page. If the Build and Push step succeeds, you can find the uploaded image in JFrog.

tip

You can also:

Build and Push to Docker step settings for JFrog Docker registries​

These sections explain how to configure the Build and Push an image to Docker Registry step settings for JFrog. Depending on the build infrastructure, some settings might be unavailable or optional. Settings specific to containers, such as Set Container Resources, are not applicable when using a VM or Harness Cloud build infrastructure.

Name​

Enter a name summarizing the step's purpose. Harness automatically assigns an Id (Entity Identifier) based on the Name. You can change the Id until the step is saved. Once save, the Id can't be changed.

Docker Connector​

Specify a Harness Docker Registry connector configured for JFrog.

To create this connector:

  1. Go to Connectors in your Harness project, organization, or account resources, and select New Connector.
  2. Select Docker Registry under Artifact Repositories.
  3. Enter a Name for the connector. The Description and Tags are optional.
  4. For Provider Type, Select Other.
  5. In Docker Registry URL, enter your JFrog URL, such as https://mycompany.jfrog.io.
  6. In the Authentication settings, you must use Username and Password authentication.
    • Username: Enter your JFrog username.
    • Password: Select or create a Harness text secret containing the password corresponding with the Username.
  7. Complete any other settings and save the connector. For information all Docker Registry connector settings, go to the Docker connector settings reference.
JFrog URLs

The JFrog URL format depends on your Artifactory configuration, and whether your Artifactory instance is local, virtual, remote, or behind a proxy. To get your JFrog URL, you can select your repo in your JFrog instance, select Set Me Up, and get the repository URL from the server name in the docker-login command.

For more information, go to the JFrog documentation on Repository Management and Configuring Docker Repositories.

Docker Repository​

The repo where you want to store the image and the image name, for example, mycompany.jfrog.io/REPO_NAME/IMAGE_NAME.

Tags​

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

Add each tag separately.

tip

When you push an image to a repo, you tag the image so you can identify it later. For example, in one pipeline stage, you push the image, and, in a later stage, you use the image name and tag to pull it and run integration tests on it.

Harness expressions are a useful way to define tags. For example, you can use the expression <+pipeline.sequenceId> as a tag. This expression represents the incremental build identifier, such as 9. By using a variable expression, rather than a fixed value, you don't have to use the same image name every time.

For example, if you use <+pipeline.sequenceId> as a tag, after the pipeline runs, you can see the Build Id in the output.

And you can see where the Build Id is used to tag your image in the container registry:

You can use the same expression to pull the tagged image, such as namespace/myimage:<+pipeline.sequenceId>.

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.

For information about setting other kaniko runtime flags, go to Environment variables.

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.

Kubernetes cluster build infrastructures

Kaniko, which is used by the Build and Push step with Kubernetes cluster build infrastructures, 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

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

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.

Docker layer caching and Remote cache image​

There are two ways in which you can leverage Docker Layer Caching: Enable Docker layer caching ('caching' property) or Remote cache image ('remoteCacheRepo' property). Refer to Enable Docker layer caching for your build to learn more.

Environment Variables (plugin runtime flags)​

Build and Push steps use plugins to complete build and push operations. With Kubernetes cluster build infrastructures, these steps use kaniko, and, with other build infrastructures, these steps use drone-docker.

These plugins have a number of additional runtime flags that you might need for certain use cases. For information about the flags, go to the kaniko plugin documentation and the drone-docker plugin documentation.

How you configure plugin runtime flags depends on your build infrastructure.

Set plugin runtime flags with Kubernetes cluster build infrastructure

When using the built-in Build and Push steps with a Kubernetes cluster build infrastructure, you can use the Environment Variables setting to set kaniko plugin runtime flags.

warning

Unlike in other Harness CI steps, the Environment Variables setting in Build and Push steps only accepts the known kaniko plugin runtime flags. You must set other types of environment variables in your Dockerfile, build arguments, or as stage variables, depending on their usage and purpose in your build.

In Environment Variables, you must input a Name and Value for each variable. Format the name as PLUGIN_FLAG_NAME.

For example, to set --skip-tls-verify, add an environment variable named PLUGIN_SKIP_TLS_VERIFY and set the variable value to true.

              - step:
                  identifier: buildandpush
                  name: buildandpush
                  type: BuildAndPush---
                  spec:
                    ...
                    envVariables:
                      PLUGIN_SKIP_TLS_VERIFY: true

To build without pushing, use the no-push kaniko flag.

YAML example: Build and Push step with multiple environment variables

This YAML example shows a Build and Push to GAR step with several PLUGIN environment variables.

              - step:
                  identifier: pushGCR
                  name: push GCR
                  type: BuildAndPushGAR ## Type depends the selected Build and Push step, such as Docker, GAR, ACR, and so on.
                  spec: ## Some parts of 'step.spec' vary by Build and Push step type (Docker, GAR, ACR, etc).
                    connectorRef: GCR_CONNECTOR
                    host: "us.gcr.io"
                    projectID: "some-gcp-project"
                    imageName: "some-image-name"
                    tags:
                      - "1.0"
                      - "1.2"
                    buildArgs:
                      foo: bar
                      hello: world
                    labels:
                      foo: bar
                      hello: world
                    target: dev-env
                    context: "."
                    dockerfile: "harnessDockerfile"
                    remoteCacheImage: "test/cache"
                    envVariables: ## Specify plugin runtime flags as environment variables under 'step.spec'.
                      PLUGIN_TAR_PATH: ./harnesstarpath
                      PLUGIN_IMAGE_DOWNLOAD_RETRY: "2"
                      PLUGIN_COMPRESSED_CACHING: "false"
                      PLUGIN_USE_NEW_RUN: "true"
                      PLUGIN_GARBAGE: yoyo
Stage variables

Previously, you could set some kaniko runtime flags as stage variables. If you had done this and you are using Kubernetes cluster build infrastructure, then Harness recommends moving these kaniko plugin stage variables to the Environment Variables in your Build and Push step. Don't change non-kaniko plugin variables, such as PLUGIN_USER_ROLE_ARN.

For other types of environment variables (that aren't Build and Push plugin runtime flags), stage variables are still inherently available to steps as environment variables. However, where you declare environment variables depends on their usage and purpose in your build. You might need to set them in your Dockerfile, build args, or otherwise.

Set plugin runtime flags with other build infrastructures

With Harness Cloud, self-managed VM, or local runner build infrastructures, you can set some drone-docker plugin runtime flags as stage variable.

Currently, Harness supports the following drone-docker flags:

  • auto_tag: Enable auto-generated build tags.
  • auto_tag_suffix: Auto-generated build tag suffix.
  • custom_labels: Additional arbitrary key-value labels.
  • artifact_file: Harness uses this to show links to uploaded artifacts on the Artifacts tab.
  • dry_run: Disables pushing to the registry. Used to build without pushing.
  • custom_dns: Provide your custom CNS address.

To set these flags in your Build and Push steps, add stage variables formatted as PLUGIN_FLAG_NAME.

For example, to set custom_dns, add a stage variable named PLUGIN_CUSTOM_DNS and set the variable value to your custom DNS address.

        variables:
          - name: PLUGIN_CUSTOM_DNS
            type: String
            description: ""
            required: false
            value: "vvv.xxx.yyy.zzz"

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:

Conditions, looping, and failure strategies​

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

Troubleshoot Build and Push steps​

Go to the CI Knowledge Base for questions and issues related to building and pushing images, such as: