By default, your steps run inside a container from a standard runtime images library maintained by JFrog. You can control which runtime images your steps execute in through the Pipelines DSL.

If you need to execute your step directly on the build host node (not in a container), see Running Steps on the Host.

Default Runtime Image

The default runtime image used to execute a Bash step is a NodeJS image that matches the OS of your node pool. For a PowerShell step, the default is a .NET Core image. In both cases, the version selected is configurable as part of the Pipelines installation and an administrator may have configured a different default image in your installation. The default is usually most appropriate when your steps will only execute shell commands that are not specific to a language.

For native steps that perform language-specific operations (for example, MvnBuild or GoBuild), the default runtime image will be one appropriate to that language. Similarly, the runtime image chosen will be one that matches the OS of your node pool. Native steps without any language-specific operations will use the same default image as Bash on Ubuntu or CentOS and the same image as PowerShell on Windows Server.

Choosing Language and Version

JFrog Pipelines supports Java, C++, Node.js, .NET,, and Go programming languages out of the box. JFrog provides default images in a standard runtime images library, which already have the latest language versions pre-installed. You can use Pipelines to build with other languages by providing a custom  image, or installing the language version you need as part of your onStart configuration.

In the runtime section of your YAML configuration you can specify a language and version, which Pipelines will use to select the matching language image. This setting can be configured at a pipeline or step level.  As an example, pipeline level configuration is shown below:

  - name: pipeline_1
        type: image
            language: node
			  - "10.18.0
  • language can be set to:
    • cpp for C/C++ steps
    • dotnetcore for .NET steps (Windows Server only)
    • go for Go steps
    • java for Java-based steps
    • node for Node.js steps
  • versions can be set to the version of the language you want to run your build against. Remember to put the version in double quotes, since the parser expects a string. For example: "9.0.0".
    For information about the supported versions, see Runtime Images.

If you need an unsupported version of a language, you can either install it in the onStart section, or use a custom Docker image.

Using a Custom Runtime Image

In some cases, our standard images library might not satisfy your requirements, or you might have an internal image you want to use for step execution. Using your own custom image gives you better control over what is installed on the runtime images. It can also speed up step execution since you can pre-install dependencies into the image. 

You can configure a custom runtime image by using the configuration shown below. This can be specified at a pipeline or step level. If specified at both levels, the step configuration will take precedence.  

  - name: pipe1
        type: image
            options: "-e HOME=/root"
            registry: art            # if custom image is private, an integration is required for authentication
            sourceRepository:        # required if registry is Artifactory. e.g. docker-local
            region:                  # required if registry is AWS. e.g. us-east-1
  • name is the fully qualified name of the Docker image. 
  • tag is the Docker image tag you want to use.
  • options is any docker option you want to use in the docker run command. You also need to include the $HOME environment variable as shown if it is not already set in your image.

If your custom image is private, you will also need to create an integration with credentials for your Docker registry, and set additional values in the config:

  • registry is the friendly name of your Docker registry integration. Supported integration types are Artifactory, Docker Registry, AWS Keys, and Google Cloud
  • sourceRepository is only needed if your Docker registry is Artifactory. It is the name of the Docker registry on Artifactory.
  • region is only required if your Docker registry is AWS ECR. 

Minimum Requirements for Linux

 Any custom runtime image specified for a step that will run in a Linux host node (Ubuntu, CentOS, or RHEL) needs to include this minimum set of components:

  • bash
  • /proc/sys/kernel/random/uuid
  • sed
  • coreutils
    • date
    • mkdir
    • cp
    • mv
    • touch
    • seq
    • cat
    • basename (for users using send_notification (email) command)
    • rm
    • uniq (for users using compare_git command)
    • split (for users using encrypt_string, decrypt_string, encrypt_file, decrypt_filecommands)
  • jfrog (when using an Artifactory integration or in a native step)
  • jq
  • awk (for users using compare_git command)
  • git (for users using compare_git command or GitRepo resources))
  • gettext (for users using replace_envs, send_notification (email) commands)
    • envsubst
  • curl (for users using send_notification command)
  • base64 (for users using send_notification (email), encrypt_string, decrypt_string, encrypt_file, decrypt_file commands)
  • openssl (for users using encrypt_string, decrypt_string, encrypt_file, decrypt_file commands)

Minimum Requirements for Windows Server

Any custom runtime image specified for a step that will run in a Windows Server host node needs to include this minimum set of components:

  • PowerShell 5
  • jfrog CLI (when using an Artifactory integration or in a native step)
  • jq (for users using replicate_resource or send_notification commands)
  • git (for users using compare_git command or GitRepo resources)
  • openssl (for users using encrypt_stringdecrypt_stringencrypt_filedecrypt_file commands)