This guide is still a work in progress!
In this guide we will explore the Apps Framework that allows you to extend and enhance the capabilities in Jenkins X.
We’re still working on the ability to alter the pipeline from an app - right now our apps include a section in the README explaining how to change your
Once complete an App will be able to add, remove and alter stages of the pipeline.
Jenkins X is built on top of Kubernetes. Kubernetes is highly configurable and extensible. This extensibility forms the basis of many of the ways we recommend extending Jenkins X.
The Apps Framework consists of a number of areas:
- the install and configuration framework
- the APIs offered by Jenkins
- the data model
- pipeline extensibility
- the testing framework
- plugins for the
In this reference guide we’ll cover each of these areas in depth. We also provide a number of other resources for working with the Apps Framework:
- How To’s
Install and Configuration Framework
Jenkins X Apps are distributed as Helm Charts via Helm Chart repositories. Any Helm chart can be installed as an app
jx add app, although Jenkins X adds various capabilities to Helm Charts including:
- the ability to interactively ask questions to generate
values.yamlbased on JSON Schema
- the ability to create pull requests against the GitOps repo that manages your team/cluster
- the ability to store secrets in vault
- the ability to upgrade all apps to the latest version
Planned features include:
- integrating kustomize to allow existing charts to be modified
- storing Helm repository credentials in vault
- taking existing
values.yamlas defaults when asking questions based on JSON Schema during app upgrade
- only asking new questions during app upgrade
jx get apps- the ability to list all apps that can be installed
- integration for bash completion
APIs can be consumed from a microservice deployed to Kubernetes, from outside the cluster (with appropriate configuration for authentication) or from inside pipeline extensions.
Jenkins X APIs uses Kubernetes Custom Resources to expose its API. The API is declarative, and Jenkins X uses controllers to try to match the actual state to the desired state. Jenkins X continually takes action to achieve and maintain the desired state.
Jenkins X uses this architectural pattern itself meaning that this API is very complete.
Custom resources are exposed by the Kubernetes API server and can be accessed as REST endpoints, using
via client libraries for different platforms. Currently we offer clients for:
jx as a library
$ go get github.com/jenkins-x/jx
Source code management
The ability to add new SCM connections to Jenkins X from an app is under active development.
In the future we intend to add the ability to plug your own identity management and SSO solution in to Jenkins X.
Jenkins X ships with a series of quickstarts that provide you with pre-made applications that you can start a project with.
You can create your own quickstarts that give your team members a starting point. Read more about creating quickstarts.
You can customize the list of quickstarts available to your team making it easier for them to select the right place to start. Read more about customizing the quickstarts available.
Build environment (creds, env vars, parameters)
Build Packs & Pod Templates
In Jenkins X a Build Pack allows you to transform source code into a applications which can be deployed on Kubernetes. Build Packs are based on draft, and will automatically add:
Dockerfileto turn the code into an immutable docker image for running on kubernetes
Jenkinsfileto define the declarative Jenkins pipeline to define the CI/CD steps for the application
- helm chart in the
chartsfolder to generate the kubernetes resources to run the application on kubernetes
- a preview chart in the
charts/previewfolder to define any dependencies for deploying a preview environment on a Pull Request
If you need to add support for different languages or build tools then you will need to create a new Pod Template. A pod template defines the pod used to run the build, and consists of:
- one or more build containers for running commands inside (e.g. your build tools like
npmalong with tools we use for other parts of the pipeline like
- volumes for persistence
- environment variables
- secrets so the pipeline can write to git repositories, docker registries, maven/npm/helm repositories and so forth
Build stages are defined in the
Jenkinsfile defines the actions to take, and the order in which to
take the actions.
The order is of actions is procedural - the first action defined will be executed first. Simple conditions are supported via the
The action that can be taken are defined by the pipeline engine. In the case of a Jenkinsfile these are defined in the Pipeline Steps Reference. Typically in Jenkins X we use the
sh step which allows us to execute any shell script in the build container.
Read more about defining pipelines using the
We’re still working on adding the ability to customize build stages to the Apps Framework.
jx CLI plugins
jx CLI can be extended with binary plugins. Binary plugins are separate binaries to
jx that are entirely
responsible for their own execution (argument parsing, subcommands, platform compatibility). We strongly recommend
writing binary plugins in Go and using the Cobra CLI framework just like
itself. Binary plugins can import
jx as a library of useful functions.
Jenkins X provides a management framework for binary plugins that allows them to be automatically installed on the users machine when the relevant subcommand is called. The management framework will also take care of upgrading and removing plugins as needed. Plugins are managed by adding a custom resource to the team or cluster.