Example .github/copilot-instructions.md for tektoncd/pipeline (Copilot code review)

copilot-instructions.md

Copilot code review instructions for tektoncd/pipeline

These instructions guide GitHub Copilot when reviewing pull requests in this repository. Tekton Pipelines provides Kubernetes-style CRDs (Task, TaskRun, Pipeline, PipelineRun, and others) with controllers built on Knative's reconciler framework, and images built/deployed with ko.

General

• Respond in English and keep review comments concise and actionable.
• Prefer pointing out correctness, security, and API-compatibility issues over stylistic nits; golangci-lint, goimports, and gofmt already enforce style.
• When suggesting changes, follow idiomatic Go and the conventions already used in surrounding code.

Do not flag generated or vendored code

• Do not suggest edits to generated code. This includes everything under pkg/client/, */zz_generated*.go, generated deepcopy/listers/informers, and OpenAPI specs. These are produced by ./hack/update-codegen.sh and ./hack/update-openapigen.sh.
• Do not review or suggest changes in the vendor/ directory.
• If an API type changes, remind the author to run ./hack/update-codegen.sh (and ./hack/update-openapigen.sh when relevant) rather than hand-editing generated files.

API changes and compatibility

• Treat changes under pkg/apis/pipeline/{v1,v1beta1,v1alpha1} as user-facing API. Review them against the API compatibility policy.
• Flag backwards-incompatible changes to stable CRDs (v1.Task, v1.TaskRun, v1.Pipeline, v1.PipelineRun): renamed/removed fields, changed defaults, changed validation, or changes to step ordering/naming and propagated labels.
• New behavior should generally be gated behind a feature flag (alpha/beta) per the feature-gates policy. Check that new fields have appropriate stability.
• v1beta1 CRD types are deprecated (bug fixes only). Push new features to v1.
• Ensure new or changed API fields have corresponding validation (Validatable) and defaulting (Defaultable) logic, and that webhook registration is updated where needed.

Controllers / reconcilers

• Reconcilers (pkg/reconciler/) must be idempotent and stateless: they reconcile current desired state, not events. Flag logic that assumes a specific triggering event.
• Watch for unbounded requeues, missing status updates, and mutation of shared informer cache objects (always deepcopy before mutating).
• Status conditions should accurately reflect outcomes; check that error paths set conditions appropriately.

Testing

• New behavior and bug fixes should include unit tests alongside the code.
• E2e tests must be build-tagged (// +build e2e / //go:build e2e) and live under test/.
• Prefer table-driven tests consistent with existing patterns; check that error cases are covered, not just the happy path.

Security & operational concerns

• Be vigilant about anything constructing pod specs, mounting volumes, handling workspaces/credentials, or running the entrypoint — flag privilege escalation, injection, or path-traversal risks.
• Avoid logging secrets or credential contents.

Documentation & housekeeping

• User-facing changes should update relevant docs under docs/.
• Deprecations should be reflected in docs/deprecations.md.
• Remind authors to run make test-unit, make golangci-lint, and the appropriate ./hack/* regeneration scripts before merge.