Official Helm Chart

[MLBMatt]

I can't seem to find an official Tekton Pipelines helm chart. It looks like the JX team has their own implementation of it but it looks tuned to JX. Is there any plan (or one that currently exists) for an officially supported Helm chart?

[vdemeester]

There is not plan for an official helm chart that I know of. We are working on providing a operator (see tektoncd/operator) for installation purpose.

That said, it might make sense to have one ?

/kind question

[eddycharly]

@MLBMatt i wrote an helm chart with pipeline and dashboard. My plan was to add triggers before making it public.

I also wrote an helm chart for prow so that I can set up my full ci/cd solution from helm.

It’s not official though, but I will be happy to contribute if there is some interest for it.

[eddycharly]

@MLBMatt i made the repo public, but keep in mind it's still work in progress. Things are subject to change as i work on it.

https://github.com/eddycharly/helm-prow-tekton/tree/master/helm/tekton

[eddycharly]

@vdemeester i think having a helm chart is great to simplify installation for the end user. It is also useful for documenting how one can configure/customize the installation, while allowing to provide default values.

Things like adding custom annotations, labels, tuning resources, etc... are so common, that's where helm really shines.

[MLBMatt]

What I really need is just a way to apply the CRDs automatically into a cluster...right now we're just leveraging a makefile to run a "setup task" that runs a bunch of kubectl apply -fs

[eddycharly]

The crds and the controller are tightly coupled. What do you mean by « just a way to apply the crds into a cluster » ?

The chart can deploy only the crds and controller. Dashboard and webhook components are optional and can be disabled.

[MLBMatt]

Like I need the https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml and https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml CRDs applied without running a kubectl apply to work seamlessly in our workflow. Bootstrapping a Tekton cluster still requires these manual steps that could be solved if they were put into and maintained in a standalone Helm chart.

[eddycharly]

I agree that an officially maintained chart would be great.

A lot of charts are created and maintained by the community though.

[adjavaherian]

I'm also contemplating a chart, but it seems like if its not part of the official repo and build process, it will quickly fall behind as issues / features are implemented and released. It looks like IBM has a community chart that's already defunct. https://github.com/IBM/charts/tree/master/community/tekton-pipelines

An official chart is certainly valuable, and doable, but i think we'd have to come up with a sensible set of parameters that can be adjusted and those would somehow have to be injected in the proper places in the new templates.

But looking at the configs https://github.com/tektoncd/pipeline/tree/master/config it seems as though the are not dynamically generated or compiled into the releases, so it might make sense to just helm-ify those directly suggest users prefer Helm ala GitHub repo.

$ helm repo add tekton-official https://raw.githubusercontent.com/tektoncd/pipeline/master/repo/chart
$ helm install tekton-official/tekton-pipelines --name <my-release> [--tls]

I think if you take that approach, you can also generate release yaml using Helm dry-run / debug to simply output default values from the templates in their current inline form.

This also seems to be agnostic from the rest of the project concerns, eg, the controller code, etc. So would be non-disruptive and would allow both a chart based and kubectl based installation from the same codebase.

[eddycharly]

Linking issue in plumbing tektoncd/plumbing#278
Various PRs in the experimental repository are linked to the issue.

This is WIP.

[salaboy]

@vdemeester or someone.. is there any update on this front?
Is there any public helm chart for pipelines?

[eddycharly]

@salaboy we couldn't integrate this in the official org, i've setup one repo here https://github.com/eddycharly/tekton-helm but it's not official

[ibexmonj]

ended up here by search for issues. +1 for an official helm chart support.

[salaboy]

An update on here, I am currently using Jenkins X Helm Charts which include and maintain a Tekton Helm Chart for their deployments, so it is up to date:

- name: tekton
    repository: https://storage.googleapis.com/chartmuseum.jenkins-x.io
    version: 0.0.56

I hope this helps...
Jenkins X relies heavily on Tekton, so I trust that these charts are well maintained and regularly updated.

[ibexmonj]

@salaboy Is this the chart you are referring to https://github.com/jenkins-x-charts/tekton ?

[salaboy]

@ibexmonj yes, I think that those are the charts that are published in their public helm chart repository linked above.

[adjavaherian]

fwiw, it looks like Helm 3 has made a conscious decision to not fully support CRDs, so its likely not a good idea to pursue a Tekton chart. https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

[ibexmonj]

@adjavaherian thats not what i interpret based on the what the docs say. They are handling CRD installs in a separate directory now crds dir vs the old crd-install. They do not say helm3 won't support CRD installs at all.

I believe there is value in adding the community chart and let the community maintain it under the official project like other open source projects do.

FWIW, there are already at least 2 separate work streams i have found that are maintaining the tekton helm charts
https://github.com/jenkins-x-charts/tekton and https://github.com/eddycharly/tekton-helm

[salaboy]

@adjavaherian I do understand that it gets confusing for updates of CRDs, but are Tekton CRDs changing that much? I mean, if they are stable enough for other projects to consume, I think that having a Helm chart is very useful,
@ibexmonj we might want to push for something like a http://cd.foundation maintained chart as a joint collaboration of multiple open source projects interested in having the charts.. @rawlingsj what do you think about this? I do believe that is a great place for collaboration

[rawlingsj]

@salaboy yeah makes sense to me. FWIW the Jenkins X helm chart is currently a little behind the latest release https://github.com/jenkins-x-charts/tekton/blob/0ead7a1b6d950aedb303df76b0ece90fac66a71d/tekton/values.yaml#L2. It would be great to setup some automation and keep up-to-date with latest releases including automated testing that could also help provide the tekton project some feedback too. If the CDF has the infrastructure to be able to do this then that sounds like a win, I'd happily help any way I can.

[tracymiranda]

@salaboy @rawlingsj great thinking - I'll take it to the CDF interoperability SIG (https://github.com/cdfoundation/sig-interoperability) and I'm sure we can get this done somehow or the other.

[bcollard]

There is not plan for an official helm chart that I know of. We are working on providing an operator (see tektoncd/operator) for installation purpose.

That said, it might make sense to have one ?

/kind question

To date, the operator looks to be under development and refactoring (for instance, I had a look two days ago, and the 'deploy' dir was renamed to 'config' between 2 pages reload). And, I suppose, this operator would require the OLM (Operator Lifecycle Manager). I guess not everyone has got this OLM installed / available (even if easily installable).

So, in the meantime, I would suggest to rely on a Helm chart. Personally, I succeeded in using the charts provided by @eddycharly (and could make PR to use the latest version of pipelines and dashboard).

[vdemeester]

To date, the operator looks to be under development and refactoring (for instance, I had a look two days ago, and the 'deploy' dir was renamed to 'config' between 2 pages reload). And, I suppose, this operator would require the OLM (Operator Lifecycle Manager). I guess not everyone has got this OLM installed / available (even if easily installable).

So, the goal of tektoncd/operator is to make it usable without requiring OLM, so that you can just apply the operator yaml and that takes care of the rest (installing or upgrading tekton, …). cc @nikhil-thomas @sthaha . It is indeed in refactoring to allow such thing (and also to allow having customization per targets like openshift, gke, …)

[salaboy]

@imjasonh perfect.. let me send a PR there.
Thanks

[vince-franco]

Would it make more sense for the Operator to have a helm chart instead of just pipelines?

[vdemeester]

Would it make more sense for the Operator to have a helm chart instead of just pipelines?

What do you mean by that ? 🤔 By Operator, I assume you don't mean tektoncd/operator as it allows you to install, manage and kustomize you pipeline installation as well as other components.

[vince-franco]

@vdemeester I do!

There's no easy way to deploy the Tekton Operator yaml and the Config yaml without running kubectl from a local machine. A really simple helm chart that would install the operator on a cluster and allow you to choose which install config profile you wanted "basic, default, all" would be really helpful. I could use the HashiCorp Terraform Helm Provider to install the operator rather than what I do now. Download a local copies of the install yaml and config yaml into my IAC repo then deploy them with a third party Terraform Provider that can apply yaml files.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[onedr0p]

/remove-lifecycle stale

[vdemeester]

@vdemeester I do!

There's no easy way to deploy the Tekton Operator yaml and the Config yaml without running kubectl from a local machine. A really simple helm chart that would install the operator on a cluster and allow you to choose which install config profile you wanted "basic, default, all" would be really helpful. I could use the HashiCorp Terraform Helm Provider to install the operator rather than what I do now. Download a local copies of the install yaml and config yaml into my IAC repo then deploy them with a third party Terraform Provider that can apply yaml files.

Yeah that could work tbh.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[nikhil-thomas]

Would it make more sense for the Operator to have a helm chart instead of just pipelines?

@vince-franco
That makes a lot of sense. 🧑‍💻 👍

At present, 2 ways to install Tektoncd/operator are:

• kubectl apply
• from operatorhub.io (for this a user will have to install OperatorLifecycleManager on a cluster first)

I think providing a helm chart for operator will be an improvement compared to the available options, as it would help us leverage an existing popular tool.

However, I think separate helm chart for individual Tektoncd Components (pipeline, triggers, chains) etc, is not good way to solve go. As this could create unnecessary overhead in the release/maitenance of components.

[nikhil-thomas]

/remove-lifecycle stale

[nikhil-thomas]

tektoncd/operator#543

[rouke-broersma]

Just to follow up, version 0.21.0 CDF Tekton helm chart has been released.

FWIW the process to upgrade with a new Tekton release is relatively simple, anyone can fork the repo, run make fetch (you'll need the jx v3 cli on your path), review the changes, push and make a pull request.

A merge to the mainline will create a new helm chart release. FWIW Jenkins X then has automated PRs generated on downstream repos that trigger BDD testing to verify Jenkins X features work before we release it to users. Ideally we will move some of this BDD testing onto the CDF Tekton helm chart repo itself so we have CI to verify the make fetch works and the proposed helm chart changes can be verified.

FYI this chart has not been updated in a while and does not include 0.27.3 which means that the chart currently does not install on k8s 1.22. We found this out the hard way..

[nikhil-thomas]

Thank you for the heads up.
At present, we are working on the possibility of providing Helm charts with the tektoncd/operator.

Initially, our idea is to support customizations such as:

• target namespace: installing Pipelines, Triggers etc in a namespace other than tekton-pipelines
• enable/disable components: install 1 or n components out of Pipelines, Triggers, Dashboard and Results.

[Obirah]

Suggestion: please make sure that the Helm chart also supports customizing the operator image(s), see #610.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.