Container Runtimes

JFrog Pipelines Documentation

ft:sourceType
Paligo

For maximum flexibility, Pipelines' preferred mode is to execute its steps in containers. For each step, Pipelines spins up a container on a build node using a Docker image that includes the runtime environment.

Step and Container.png

Through this method, each step executes with the runtime it needs to perform its particular set of work. For example, it can have the binaries and libraries needed for a language, and/or it can have tools and CLIs that the step needs to perform automated tests.

Steps and Containers Horz.png

This system offers several key benefits:

  • Each step executes with the tools it needs, and no others, configured with the specific settings for that environment.

  • Steps in the same pipeline can execute in different runtimes, if they need a unique configuration or set of tools.

  • Steps can execute simultaneously in different build nodes (when available), for faster build times.

  • Pipelines are fully repeatable, always executing using the same set of immutable, versioned Docker images.

  • Different teams can build with different tools and configurations without impacting each other.

  • Pipelines can reliably execute with the runtime (including credentials) appropriate for the build environment, whether for Dev, Test, or Production.

  • Execute pipelines on whichever infrastructure suits your needs best: on virtual machines hosted by a cloud provider or on servers in your own datacenter.

JFrog provides a set of standard Docker images of runtimes for supported architecture, OS, and language combinations. When the Pipelines DSL doesn't specify a runtime, Pipelines provisions the build node with one of these runtime images as best matches the build node environment.