Renovate should keep Tekton and Argo k8s manifests up-to-date

[jonashackt]

Currently the Kubernetes manifests in our GitHub Actions workflow aren’t kept up to date.

[jonashackt]

We should use https://helm.sh/ here?

Traefik is now beeing held up to date by Renovate #57

[jonashackt]

I think https://kustomize.io/ as now used for ArgoCD installation from e713e57 on could be a fantastic option here with only a minimal overhead https://docs.renovatebot.com/modules/manager/kustomize/

[jonashackt]

Should be implemented now - we observe it in the next days and maybe reopen.

[jonashackt]

Seems to not work out-of-the-box 🥲

Renovate docs https://docs.renovatebot.com/modules/manager/kustomize/
they link to Kustomize docs https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md

For example,

https://github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6

https://github.com/kubernetes-sigs/kustomize/tree/v1.0.6/examples/multibases/dev

works only inside kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:

• https://github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6

• https://github.com/argoproj/argo-cd//manifests/install.yaml?ref=v2.3.3

Argo install docs state:

https://raw.githubusercontent.com/argoproj/argo-cd/v2.3.3/manifests/install.yaml

which references:

https://github.com/argoproj/argo-cd/blob/master/manifests/install.yaml

cat > ./kustomization.yaml <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- https://github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6

EOF

And then kustomize build . works:

kustomize build .
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: myapp
  name: dev-myapp-pod
spec:
  containers:
  - image: nginx:1.7.9
    name: nginx

But sadly

cat > ./kustomization.yaml <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- https://github.com/argoproj/argo-cd//manifests/install.yaml?ref=v2.3.3

EOF

does not:

$ kustomize build .
Error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/argoproj/argo-cd//manifests/install.yaml?ref=v2.3.3': URL is a git repository': '/private/var/folders/5p/l1cc1kqd69n_qxrftgln7xdm0000gn/T/kustomize-1732093150/manifests/install.yaml' refers to file 'install.yaml'; expecting directory

[jonashackt]

For Tekton it seems that kustomize doesn't support files on Google Cloud Storage and the https://github.com/tektoncd/pipeline project doesn't hold a kustomization.yaml we could pick up as we can with ArgoCD. According to tektoncd/pipeline#4509 there is a Tekton project plumbing which holds kustomization.yamls - see https://github.com/tektoncd/plumbing/tree/main/tekton/resources/release - but this repo isn't intended to be used for outside release updates IMHO.

So maybe we can switch over to Helm? This is discussed in this issues:

• Official Helm Chart tektoncd/pipeline#1542
• Helm chart tektoncd/plumbing#278
• Add pipeline helm chart tektoncd/experimental#494

There's also a Helm chart available in the experimental repo https://github.com/tektoncd/experimental/tree/main/helm - but sadly it doesn't seem to be maintained that well.

When I get the issues right, the Tekton team doesn't really know about Helm (see tektoncd/pipeline#1542 (comment)) and thus doesn't want to support it - which is quite interesting for the "Cloud Native CI/CD framework". Either Kustomize or Helm should be fully supported and maintained I guess.

But there seems to be another way: Using the Jenkins X Helm Chart (tektoncd/pipeline#1542 (comment)) which has beem moved over to the cdfoundation GitHub orga: https://github.com/cdfoundation/tekton-helm-chart (but it's not clear, if the Chart is 100% up to date - see tektoncd/pipeline#1542 (comment)).

So in the end we should maybe use the Tekton Operator and delegate the update process to it? https://github.com/tektoncd/operator