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.
runtime section of your YAML configuration you can specify a
version, which Pipelines will use to select the matching language image. This setting can be configured at a
step level. As an example, pipeline level configuration is shown below:
pipelines: - name: pipeline_1 configuration: runtime: type: image image: auto: language: node version: "16" # Either "version" or "versions" can be used. versions: - "16"
Can be set to:
|Can be set to a single 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.
Can be set to multiple versions 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".
If you need an unsupported version of a language, you can either install it in the
onStart section, or use a custom Docker 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> # may be required if registry is Artifactory. e.g. docker-local region: <string> # required if registry is AWS. e.g. us-east-1
|This is the fully qualified name of the Docker image.|
|This is the Docker image tag you want to use.|
|This is any Docker option you want to use in the |
|This is an option to automatically pull the image to the machine running the step. Defaults to |
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:
|This is the friendly name of your Docker registry integration. Supported integration types are Artifactory, Docker Registry, AWS Keys, and Google Cloud.|
The is not used with JFrog CLI v2.
This is only needed if your Docker registry is Artifactory and the pipeline is configured to use JFrog CLI v1. It is the name of the Docker registry on Artifactory.
|This is only required if your Docker registry is AWS ECR.|
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
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:
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: