Pipelines and tasks are namespace-agnostic: they have no hardcoded namespace in metadata. You apply them to the namespace you want and run PipelineRuns in that same namespace. This supports a three-tier flow: local (Kind) → test namespace → production namespace.
- Local (Kind) — Run pipeline changes locally via
generate-run.sh. Fast iteration. - Test namespace (e.g.
tekton-test) — Apply pipeline/task/trigger YAML to a dedicated namespace; trigger runs against test repos/branches. Validate before promoting. - Production namespace (e.g.
tekton-pipelines) — Promote proven pipeline versions here. Webhook-triggered runs from real PRs/merges.
Create a namespace with ServiceAccount, RBAC, secrets, build-cache PVC, catalog tasks, and this repo’s tasks/pipelines:
./scripts/bootstrap-namespace.sh tekton-test
# Optional: --ssh-key, --github-token, --webhook-secretDefault namespace if you omit the argument is tekton-pipelines.
- Env var:
NAMESPACE=tekton-test ./scripts/generate-run.sh --mode pr --repo demo-fe --pr 1 --apply - Flag:
./scripts/generate-run.sh --mode pr --repo demo-fe --pr 1 --namespace tekton-test --apply
Generated PipelineRuns use the given namespace. Apply with kubectl create -f - (or --apply) so they run in that namespace.
After validating in a test namespace, apply the same YAML to production:
./scripts/promote-pipelines.sh --from tekton-test --to tekton-pipelines
# Optional: --dry-run to print without applyingThis applies tasks/ and pipeline/ from the repo into the target namespace. Promotion is manual — the operator decides when a pipeline version is ready for production.
Each namespace has its own EventListener and Service. Webhook URLs must target the namespace you want (different host, path, or port). See m4-eventlistener-per-namespace.md.
Pipeline and task resources are labeled with app.kubernetes.io/version: "1.0.0" so operators can see which version is deployed in each namespace. Update the version in the YAML when you cut a new pipeline release.