Tekton has been designed to be a modern cloud native solution for running pipelines.
The work here is still experimental but we’d love feedback and help from the community to drive it forward.
Trying Jenkins X Pipelines
Right now to enable a Tekton based install you can create a new cluster using jx along with these flags:
jx create cluster gke --tekton --no-tiller
Or if you want to go all in on the next generation of Jenkins X with built in GitOps for your development environment, using Tekton and using Vault for storage of Secrets then use the following (only works on GCP and AWS right now):
jx create cluster gke --ng
The general developer experience, CLI and IDE plugins should work as before - but using Tekton Pipelines Custom Resources under the covers instead of creating a Jenkins Server per team!
Using a quickstart
Once your cluster is started you can create a new quickstart, we’ve been using the nodejs one reliably.
jx create quickstart
A prowjob is created, a new prow pipeline controller watches for these jobs and when it receives and event will check if it has a pipelinerun spec present, if not it will post the prowjob to a new pipelinerunner service from Jenkins X which in turn clones the repo and revision then translates it’s jenkins-x.yml into vanilla Tekton Pipeline resources. Once they are created the tekton-pipeline-controller executes the builds.
Differences to Jenkins Pipelines
Jenkins X Pipelines use a new jenkins-x.yml file which is YAML instead of the Groovy Jenkinsfile used by Jenkins.
However its still reusing the same reusable and composable build packs under the covers. (The Jenkins X build packs are actually written in Jenkins X Pipelines YAML).
One thing you will notice is that with Jenkins X Pipelines we don’t need to copy/paste a large Jenkisnfile into each applications git repository; usually the generated jenkins-x.yml file is small, like this:
Thats it! What that basically means is at runtime the Jenkins X Pipeline will use the build packs to generate the actual Tekton Pipeline.
Customising the Pipelines
Having automated build packs to do all of your CI+CD is pretty awesome - as most of the time your microservices will all be compiled, tested, packaged, released and promoted in the same way. CI+CD is often undifferentiated heavy lifting we should just automate!
However there are times you want to customise a particular pipeline (release, pull request, feature etc) and a particular lifecycle to change the actual steps invoked.
You can read more about the extension model to find out all you can do. Basically you can add steps before/after any lifecycle or completely replace a set of lifecycles or even opt out of the build pack completely and inline your pipelines inside your jenkins-x.yml
For a quick way to add a new step into a pipeline lifecycle you can use the jx create step command:
You can also add or override an environment variable in your pipeline via the jx create variable command
Default environment variables
The following environment variables are available for use in a step in Jenkins X Pipelines:
the docker registry host (e.g. docker.io or gcr.io)
the build number (1, 2, 3) starts at 1 for each repo and branch
the kind of pipeline such as release or pullrequest
the pipeline context if there are multiple pipelines per PR (for different tests/governance/lint etc)
the git repository owner
the git repository name
the job name which tyically looks like $REPO_OWNER/$REPO_NAME/$BRANCH_NAME
the name of the app which typically is the $REPO_NAME
the name of the branch such as master or PR-123
indicates to jx to use batch mode if true
contains the version number being released or the PR’s preview version
same as $BUILD_NUMBER
the prow job type such as presubmit for PR or postsubmit for release
the branch/ref of git
the git sha being built
for PRs this will be the number without the PR- prefix