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)
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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