Skip to content

Files

Latest commit

michaelsautermichaelsauter
Add more decision docs
May 11, 2021
2c5e9ba · May 11, 2021

History

History
36 lines (20 loc) · 3.43 KB

20210511-tekton.md

File metadata and controls

36 lines (20 loc) · 3.43 KB

Using Tekton

Rationale

We will base our implementation on OpenShift Pipelines, which basically is Tekton.

We use OpenShift Pipelines because it is nicely integrated in OpenShift (they provide a UI).

Rejected Alternatives

Jenkins

This is where we're coming from. Comparison:

  • Jenkins uses a long-running service (the "Jenkins master"), whereas Tekton does not have a server component by itself. OpenShift Pipelines offers a basic UI to view pipeline runs and their logs. However, several functionalities like Jenkins job attachments are not available in OpenShift Pipelines. One advantage of not having a server component is the reduction of memory usage, which is typically around 5GB per Jenkins instance.
  • Jenkins can be extended with plugins. This is not possible with OpenShift Pipelines. Some functionality provided by plugins can be covered by Tekton tasks, which make use of images providing certain tooling.
  • To avoid repeating common pipeline tasks, ODS shipped with a "Jenkins shared library". This library defines several stages which can be called from the application's Jenkinsfile. The Tekton tasks provided by ODS can be seen as a replacement for the shard library concept. The ods.yml file defining the tasks can be seen as a replacement for the Jenkinsfile.
  • Jenkins allows to script pipelines with Groovy. This opens a lot of possibilites and makes Jenkins very flexible. However, this flexibility comes at a cost as well: it introduces additional complexity and increases the likelihood of bugs. Further, to support resuming pipelines, Jenkins applies so called CPS transformation to the Groovy source code which can have very surprising behaviour and requires a lot of detailed knowledge about the inner workings of Jenkins.
  • The Jenkins master/agent concept led to a brittle master/agent dance back-and-forth in the shared library orchestration pipeline because some things need to run on the master (e.g. executing sub-pipelines), and other things need to run on the agent (e.g. external cluster deploy).

Jenkins X

This does not have a lot in common with "classic Jenkins", and is actually based on Tekton.

At the time of writing, the project seems a bit all over the place. It is going through a big change from v2 to v3, and the documentation is not great yet, so it is hard to understand what it really is or is not. Maybe that is also because the project is not clear on where its boundaries are.

Also, it has quite a few abstractions over Tekton, see for example https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/. It describes an approach for sharing steps that they wanted to contribute upstream, which more or less got rejected, see tektoncd/community#369. The direction of Jenkins X does not feel good long-term.

RedHat Advanced Cluster Management

Does not have much traction outside IBM/RedHat. Also, it seems to be more centered on clusters. Regarding application lifecycle management, we might want to look into this GitOps/Subscription concept, but it seems like RHACM is more focused on CD, and does not replace CI. Therefore exploring Tekton for CI right now makes sense, and maybe we do find a place for RHACM later for deployment to multiple clusters.

ArgoCD

TODO