tektoncd / tektoncd/operator

TektonConfig auto-install fails when the webhook service is not named tekton-operator-webhook (kodata hardcodes service.name; WEBHOOK_SERVICE_NAME env is ignored for clientConfig)

Open
#4,123 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
608
Forks
263
Avg merge
1d 3h
Merged PRs (30d)
125

Description

Related: #624 (closed in 2022 — reopening the case since the Helm chart makes non-default service names common).

What happened: Installing the operator with any service name other than tekton-operator-webhook leaves the operator and webhook pods healthy, but TektonConfig auto-install fails:

Failed to create TektonConfig instance ... failed calling webhook "webhook.operator.tekton.dev":
Post "https://tekton-operator-webhook.tekton-operator.svc:443/defaulting?timeout=10s":
service "tekton-operator-webhook" not found   (pkg/reconciler/shared/tektonconfig/instance.go:91)

Repro (verified on kind v1.34.0 with the v0.81.1 chart, any release name ≠ tekton-operator): helm install to charts/tekton-operator … → the webhook service is to-tekton-operator-webhook, but the MutatingWebhookConfiguration registered by the webhook binary points at the literal tekton-operator-webhook.

Root cause: cmd/{kubernetes,openshift}/webhook/kodata/validating-defaulting-webhook/500-webhooks.yaml pins service.name: tekton-operator-webhook. The WEBHOOK_SERVICE_NAME env var (cmd/*/webhook/main.go) flows into kwebhook.Options but only affects cert rotation and leader election — the kodata clientConfig is applied as-is.

Fix directions: rewrite the kodata webhook configs' clientConfig (service name + namespace) from Options.ServiceName/system namespace before applying; or document that the service must keep the default name.

Full verification details in the evidence comment on #3945.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with cmd/{kubernetes,openshift}/webhook/kodata/validating-defaulting-webhook/500-webhooks.yaml and trace WEBHOOK_SERVICE_NAME from cmd/*/webhook/main.go into kwebhook.Options. Check how the kodata clientConfig is applied during webhook setup. Done means a non-default Helm release name produces a MutatingWebhookConfiguration targeting the actual webhook service and TektonConfig auto-install succeeds.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, helm, kubernetes
Domain
backend, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.