Working with build packs in CloudBees Jenkins X Distribution

Working with build packs in CloudBees Jenkins X Distribution

CloudBees Jenkins X Distribution utilizes a series of scripts and configuration files that set the appropriate options, parameters, and dependencies to reduce the complexity of setting up a CI/CD development environment.

CloudBees Jenkins X Distribution employs build packs to automate the creation of applications. The build packs are based on the draft open-source build and deployment tool for Kubernetes.

Build pack components

The build packs contain various default files if they do not already exist in the project being created or imported:

  • Dockerfile to build your application as a docker image on Kubernetes.

  • Jenkinsfile to define the declarative pipeline and the CI/CD process for your application.

  • Helm chart in the charts folder to create the resources for running your application inside Kubernetes.

  • a preview chart in the charts/preview folder to define any dependencies for deploying a preview environment on a Pull Request

Build pack file locations

Creating a Jenkins X cluster using jx boot clones the build packs to your local .~/.jx/draft/packs/ folder and updates them via git pull each time you run jx create cluster or jx import.

Supported build packs

The default build packs are located in the official Jenkins X GitHub repository with a folder for each language or build tool. Build packs currently supported by CloudBees Jenkins X Distribution include:

  • Maven - The build tool for Java software projects that automates build procedures and manages dependencies, using editable XML configuration files that specify build details. The system downloads any required Java libraries and plugins required by Maven for a project build, along with updating artifact repositories when necessary.

  • Go - A programming language developed by Google that focuses on readability, dynamic high-level syntax, building projects remotely and using multi-core or distributed processing, and a compiler that is built for portability to multiple OSes and mobile platforms

  • Gradle - An open source build tool in Java that is considered a successor to Maven and extends it using the Groovy language that makes configuring and building Java projects using a _domain-specific language (DSL) authoring environment.

  • Node - Node is a JavaScript runtime environment for creating standalone programs that do not require a web browser to execute. Node is often used to create backend tools and scripts for scalable network-based applications.

    The javascript build pack supports the Node.js runtime environment as well as the Node Package Manager (npm).

  • Spring - An open source application framework that builds Java applications across various platforms. It features support for both Groovy and Kotlin languages, and scales from individual developer workloads like batch write/read to cloud developers quickly deploying one .jar file to a cloud service, up to enterprise-level projects that require stability and security over dynamic functionality.

    Spring projects can be configured using the jx import to incorporate existing projects into CloudBees Jenkins X Distribution or can leverage Spring Boot and automate the import of your project.

Extending build pack functionality

With the development of CloudBees Jenkins X Distribution, build packs have been refactored so that they are more modular and easier to compose and reuse across workloads.

For example the jenkins-x-kubernetes build pack inherits from the jenkins-x-classic build pack, reusing the CI and release pipelines, then adds the kubernetes specific workloads (e.g. building docker images, creating helm charts, preview environments, and GitOps promotion.

Jenkins X uses a jenkins-x.yml YAML configuration file for pipeline configuration of build packs. For detailed information about Pipelines, refer to Using Jenkins X Pipelines.

Creating custom build packs

Users can create custom build packs, either from scratch or using existing quickstart applications. Refer to link:Using quickstarts[/docs/jenkins-x/cloudbees-jenkins-x-distribution/creating-quickstarts/] for more information.

When creating a quickstart, you must manually add a Dockerfile and Jenkinsfile if one is not already added for you. You could use files from the current build pack folders using a compatible language or framework similar to your project.

Once you have a pod template to use, say, jenkinsx-pack then refer to it in your Jenkinsfile:

// my declarative Jenkinsfile

pipeline {
    agent {
      label "jenkinsx-pack"
    environment {
    stages {
      stage('CI Build and push snapshot') {
        steps {
          container('foo') {
            sh "foo deploy"

Once your Jenkinsfile is capable of doing CI/CD for your language/runtime on your sample project then you should be able to take the Dockerfile, Jenkinsfile and charts folder and copy them into a folder in your fork of the jenkins-x/draft-packs repository.

You can try that out locally by adding these files to your local clone of the build packs repository at ~/.jx/draft/packs/

For example:

export PACK="foo"
mkdir ~/.jx/draft/packs/$PACK
cp Dockerfile Jenkinsfile  ~/.jx/draft/packs/$PACK

# the charts will be in some folder charts/somefoo
cp -r charts/somefoo ~/.jx/draft/packs/$PACK/charts

Once your build pack is in your local packs directory at ~/.jx/draft/packs/ then it should be usable by the jx import which uses programming language detection to find the most suitable build pack to use when importing a project.

If you have any questions or feedback on the CloudBees Jenkins X Distribution documentation, send them to