Easily reuse Tekton and Jenkins X from Jenkins

Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premises systems.

Jenkins is the most popular open source automation server around. Lots of developers use it every day to get things done. Jenkins can now be used to automate Tekton pipelines too which helps teams digitally transform to more cloud native solutions for their CI and CD. In such a case, you can use Tekton pipeline engine while getting all benefits from Jenkins as an orchestrator, user interface and the reporting engine.

The Tekton Client plugin for Jenkins lets you easily use Jenkins to automate creating and running Tekton pipelines. It bridges the Kubernetes learning gap and allows invoking Tekton Pipelines and resources through Jenkins. This allows users to not have much of the Kubernetes specific knowledge beforehand and work.

Its a single Jenkins plugin to install - so it’s easy to use.

For background check out the blog post Bridging the Gap with Tekton-client-plugin for Jenkins by the founder of the plugin Vibhav Bobade.

The Tekton Catalog defines a ton of Tekton Tasks you can reuse in your pipelines

We have found when it comes to a microsevices style architecture you end up with lots of repositories and pipelines. Then using a Pipeline As Code pattern with GitOps we want to Version Everything but also make it easy for any repository to use any version of any task or pipeline.

e.g. you may have many repositories using the current version of a pipeline but want to try out a new change to the pipeline in just 1 repository to verify it works well; then if it does, incrementally roll that change out to more repositories.

This can make it hard trying to reuse as much as you can across the different git repositories while also minimising the number of versions and forks of git repositories you have and simplifying the maintenance of all of the pipelines.

We have found on the Jenkins X project that a nice way to do this via GitOps such that we reference versioned Tekton Tasks and Pipelines in git so that they are easy to reuse or override.

So we reuse Tasks and Pipelines via the uses: image notation which lets us keep all of our Tekton Tasks and Pipelines in vanilla Tekton YAML; so that the IDE completion and validation works - but we can easily reuse Tasks or steps from libraries while also Versioning Everything

Note that if wish to reuse steps/tasks via the uses: image notation then you must click the Tekton Catalog flag in your Job definition which will then resolve the uses: clause with the actual step/task.

The Jenkins X project automates your CI/CD on kubernetes to help you accelerate:

All of the above is implemented in reusable Tekton pipelines.

Being able to reuse steps from libraries of pipelines is awesome; but sometimes you need to change things. The assumptions, commands, arguments, environment variables or approaches used for every step in a library may not quite match what you need on a specific application. You may need to run steps before/after steps in the library or you may need to override a specific step to do something different.

You can easily customize any inherited step in any shared pipeline or add custom steps before/after any step.

The fact that all the Tekton YAML is fully declarative makes it super easy to modify things via your IDE with validation and smart completion and not have to use a scripting language and understand complex shared pipeline libraries.

The easiest way to try overriding a step is to install the jx binary to your $PATH then use the jx pipeline override command which will create a new locally overridden step you can then just edit in your IDE.

Then at any time you can view the effective pipeline when you make local changes

Those of you using Jenkins on a Kubernetes cluster are probably using the kubernetes plugin right now.

Here is an example of how to use a Jenkinsfile with a pod YAML file so that you can run commands in different containers in the pod.

What this means is that:

This has a few issues:

Though one downside of the tekton approach is that by default there is no automatic synchronisation of state; after a Task in tekton completes there’s no automatic upload of state to the Jenkins controllers disk. You can always add a step in your Task to upload workspace state to the Jenkins controller if that’s what you want.

Though remember that tekton plugin doesn’t take anything away; so you can mix and match the kubernetes and tekton plugins to suit your needs.

We are really excited about the combination of Jenkins, Tekton and Jenkins X letting developers pick the best tool for the job while becoming more cloud native and increasing the automation help reduce the amount of manual work creating and maintaining pipelines while also helping to improve the quality and practices of our CI/CD.

Please try it out and let us know how you get on!