WARNING: Jenkins X version 2.x is unmaintained. Do not use it.

Please refer to thev3 documentation for the latest supported version.

Jenkins X Pipelines

In continuous delivery (CD) environments, apipeline is a process (expressedas a collection of commands or plugins and a configuration file to express thedevelopment process) that automates the life cycle from repository source filesto production deployment.

Jenkins X Pipelines is aserverless pipeline execution enginebased on theTekton Pipelines open sourceproject. Tekton has been designed to be a modern cloud native solutionfor running pipelines.

Jenkins X pipelines are configured in YAML configuration files. The files can befound in two locations serving distinct purposes:

• In the Jenkins X project repository, calledjenkins-x.yml.
• In the build packs for creating applications, if it is specified in the project repositorypipeline.yaml file underbuildPack.

Pipeline types

Each pipeline YAML file has a number of separate logical pipelines:

• release for processing merges to the master branch which typically creates a new version and release then triggers promotion
• pullRequest for processing Pull Requests
• feature for processing merges to a feature branch. Consider using trunk based development which is a practice of high performing teams.

Lifecycles

Jenkins X has various steps in building, validating, and releasing yourapplication through the development lifecycle. The lifecycle phases in theJenkins X pipeline YAML configuration are:

• setup - Steps to create the build environment, such as checking out codewith git checkout or generating credentials files for Git providerauthentication

• preBuild - Steps to perform before a build occurs, such as ensuring a Dockerimage registry is available for building

• build - Steps performed to build your application

• postBuild - Steps performed after the build occurs, such as validating forCommon Vulnerability Exposure (CVE) in any code changes.

• promote - Shifting the state of an application (after build and validation)to another environment, such as Staging or Production.

Understanding Jenkins X pipelines

The Jenkins X cluster configuration process creates a YAML-based pipelineconfiguration file called jenkins-x.yml. This file configures the defaultdevelopment pipeline for building applications on kubernetes clusters withJenkins X.

buildPack: nonepipelineConfig:  pipelines:    release:      pipeline:        agent:          image: gcr.io/jenkinsxio/builder-go

buildPack specifies a build pack which contains apipeline.yml file thatsupersedes thejenkins-x.yml file in the project directory. If none isspecified, there is no build pack and Jenkins X uses the default pipelineconfiguration.

The configuration defines the pipeline agent, in this case a Google ContainerRegistry image for the Go language build tools.

        environment:          - name: DEPLOY_NAMESPACE            value: jx

environment specifies environment variables used in the pipelineconfiguration. In this instance, theDEPLOY_NAMESPACE variable is used with avalue ofjx for the Jenkins X namespace.

        stages:          - name: release            steps:              - name: verify-preintall                dir: /workspace/source/env                command: jx                args:['step','verify','preinstall']

stages are unique groups of steps (or nested stages sequentially run within astage) that specify commands, directories, and arguments for a particularpipeline stage. In this instance, there is a step within therelease stagecalledverify-preinstall that runs ajx command that verifies whether cloudinfrastructure (such as the presence of thekubectl binary and the correctversion of git is installed) was setup in the preinstallation process.

              - name: install-vault                dir: /workspace/source/systems/vault                command: jx                args:['step','boot','vault']

name calls out a unique step in the pipeline configuration that definesdevelopment steps to verify and apply arguments to various commands necessaryfor the stage under which it is nested. In this instance,install-vaultinstalls the Hashicorp Vault tool for secrets management.

              - name: apply-repositories                dir: /workspace/source/repositories                command: jx                args:['step','helm','apply','--name','repos']

This step creates and applies the Helm Package Manager for installation andmanagement of helm kubernetes applications.

              - name: apply-pipeline-schedulers                dir: /workspace/source/prowConfig                command: jx                args:['step','scheduler','config','apply','--direct=true']

This step allows the pipeline to work with a scheduler, which executes programjobs unattended in the background.

              - name: update-webhooks                dir: /workspace/source/repositories                command: jx                args:['update','webhooks','--verbose','--warn-on-fail']

This step updates webhooks, which is a service that listens for GitHub activityand trigger jobs, send automated messages to chat clients such as Slack, andother configurable actions.

              - name: verify-install                dir: /workspace/source/env                command: jx                args:['step','verify','install','--pod-wait-time','30m']

This step verifies the project installation, downloading and installing orupdating components when necessary.

    pullRequest:      pipeline:        agent:          image: gcr.io/jenkinsxio/builder-go

pullRequest is a logical pipeline within the project pipeline that specifies how pull requests are managed when changes are made to the project repository in GitHub.

        stages:          - name: release            steps:              - name: helm-build                dir: /workspace/source/env                command: make                args:['build']

ThepullRequest pipeline contains a stage wherein steps can also be executed. In this instance, make is run to create a helm chart and validate that a build has been completed.

Extending pipelines

A pipeline YAML can extend another YAML file. You can reference a base pipelineYAML using the following methods:

• Using file to reference a relative file path in the same build pack

  extends:  file: ../jenkins-x.yaml

• Using import to reference a YAML file:

  extends:  import: classic  file: maven/pipeline.yaml

which then refers to a named imported module via git:

modules:- name: classic  gitUrl: https://github.com/jenkins-x-buildpacks/jenkins-x-kubernetes.git  gitRef: master

Overriding steps

Users can override steps in a pipeline YAML from a base pipeline YAML, similar to overriding classes in languages like Java. This allows users reuse the steps in a base pipeline’s lifecycle, then add additional steps.

By default any steps you define are added after the base pipeline YAML steps. For example:

extends:  file: base-pipeline.yamlpipelines:  pullRequest:    build:      steps:      - sh: export VERSION=$PREVIEW_VERSION&& skaffold build -f skaffold.yaml

You can add steps before the base pipeline steps using the preSteps: property:

extends:  file: base-pipeline.yamlpipelines:  release:    setup:      preSteps:      - sh: echo BEFORE BASE SETUP      steps:      - sh: echo AFTER BASE SETUP    build:      replace: true      steps:      - sh: mvn clean deploy -Pmyprofile        comment: this command is overridden from the base pipeline

If you want to completely replace all the steps from a base pipeline for aparticular lifecycle you can use replace: true:

  replace: true  steps:  - sh: mvn clean deploy -Pmyprofile    comment: this command is overridden from the base pipeline

Feedback

Was this page helpful?

Glad to hear it! Pleasetell us how we can improve.

Sorry to hear that. Pleasetell us how we can improve.