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
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 an event it 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 its 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 it’s 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 Jenkinsfile into each application’s git repository; usually the generated jenkins-x.yml file is small, like this:
That’s 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
This should already be interested out of the box due to the Jenkins X JSON Schema being registered with schemastore.org so editing your jenkins-x.yml file in IDEA will include smart completion and validation!