Cloud customer?
Start for Free >
Upgrade in MyJFrog >
What's New in Cloud >

Search





Overview

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.


Page Contents


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:

pipelines:
  - name: pipeline_1
    configuration:
      runtime:
        type: image
        image:
          auto:
            language: node
            versions:
			  - "10.18.0"
TagDescription
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.  

pipelines:
  - name: pipe1
    configuration: 
      runtime:       
        type: image
        image:
          custom:
            name: <string>                	# imageRepo/imageName format
            tag: <string>             		# version tag of the initial version of the Docker image
            options: "-e HOME=/root"    	# Docker options
            autoPull: <boolean>           	# default true; pulls image before run
            registry: <integration>     	# if custom image is private, an integration is required for authentication
            sourceRepository: <path>    	# required if registry is Artifactory. e.g. docker-local
            region: <string>            	# required if registry is AWS. e.g. us-east-1
TagDescription
nameThis is the fully qualified name of the Docker image. 
tagThis is the Docker image tag you want to use.
optionsThis 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.
autopullThis is an option to automatically pull the image to the machine running the step. Defaults to true.

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:

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

Examples

Example 1

pipelines:
  - name: pipe1
    configuration: 
      runtime:       
        type: image
        image:
          custom:
            name: docker/jfrog_win
            tag: latest
            options: "-e HOME=/root"
       		autoPull: false
            registry: PSSG_DockerRegistry

Example 2 - Artifactory registry

pipelines:
  - name: pipe2
    configuration: 
      runtime:       
        type: image
        image:
          custom:
            name: ubuntu
            tag: latest
            registry: myArtifactory
      		sourceRepository: docker-local

Example 3 - AWS registry

pipelines:
  - name: pipe3
    configuration: 
      runtime:       
        type: image_aws
        image:
          custom:
            name: 541601.dkr.ecr.us-east-1.amazonaws.com/jfbeta
            tag: latest
       		autoPull: false
            registry: AWS
			region: us-east-1

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)


  • No labels
Copyright © 2021 JFrog Ltd.