tektoncd/pipeline

Feature Request Summary Kubernetes v1.36 introduced Server-Side Sharded List and Watch as an alpha feature (KEP-5866). This feature allows the API server to filter watch events at the source, so that each controller replica only receives objects within its assigned hash range — rather than the full event stream. Tekton Pipelines controllers (e.g., the PipelineRun and TaskRun reconcilers) would benefit significantly from adopting this capability, especially in large-scale environments where thousands of PipelineRuns and TaskRuns are created concurrently. Problem Today, when the Tekton Pipelines controller is scaled horizontally (multiple replicas), every replica receives the full stream of watch events for all PipelineRuns, TaskRuns, and other resources. Each replica then deserializes and processes every event, only to discard objects it isn't responsible for (via leader election or other partitioning logic). This has several consequences: N replicas × full event stream: CPU and mem

Summary TaskRunImagePullFailed (added to fail fast on ImagePullBackOff, config default-imagepullbackoff-timeout, default 0) does not distinguish transient, self-resolving image-pull errors from permanent ones. Under bursty, high-concurrency pod creation — e.g. an HA controller deployment with a high threads-per-controller value — many pods can request an image pull from the same node within a very short window, exceeding the container runtime's image-pull rate limit (CRI-O's default imagePullQPS ~5/sec/node). The resulting ErrImagePull: pull QPS exceeded is transient and normally resolves within a few seconds via Kubernetes' own backoff/retry, but with the default default-imagepullbackoff-timeout: 0, the controller kills the TaskRun on the first occurrence, before that retry can happen. Reproduction OpenShift Pipelines 1.23.0 / Tekton Pipelines v1.12.0 (commit 7ce6b655b0a061a8bdca75d3d5e18b7140f90ea3), but the code path (taskrun/taskrun.go PullImageFailed detection → TaskRunImag

Problem The bundle resolver's retry/backoff mechanism (configured via bundleresolver-config) only retries on HTTP response codes (429, 5xx). It does not retry on network-level transient errors such as: TCP connection timeouts (dial tcp ... i/o timeout) Connection resets (connection reset by peer) Broken pipes (broken pipe) EOF errors (server closed connection mid-transfer) TLS handshake timeouts These are all recoverable, transient errors that occur frequently in production environments with shared egress proxies, registry mirrors behind load balancers, or cloud NAT gateways with connection limits. Root Cause The retry logic in go-containerregistry's transport.Retry relies on net.Error.Temporary() to identify retryable network errors. However, Go deprecated Temporary() (it returns false for most errors since Go 1.18+), so network-level errors are no longer classified as retryable. The Timeout() check and connection-reset detection were added in newer go-containerregistry versions, bu

Currently, the Hub Resolver requires the catalog parameter to be set explicitly when resolving StepActions, unlike task and pipeline which have default catalogs via resolveCatalogName. We should add a default catalog for stepaction so users don't have to specify it every time, consistent with the behavior for tasks and pipelines. Ref: #10275 (comment) /kind feature

Summary When a TaskRun has multiple steps that each emit results, every step container's termination message contains all previous steps' results plus its own — they accumulate as steps complete. This contradicts the Tasks docs: If your Task writes a large number of small results, you can work around this limitation by writing each result from a separate Step so that each Step has its own termination message. Splitting results across steps actually makes the 4KB MaxContainerTerminationMessageLength limit easier to hit: the last step's container must hold the full accumulated payload. The advice was likely true ~6 years ago but is now stale. Reported by @aThorp96, confirmed empirically: a generate-results-at-once Task succeeds while an equivalent generate-results-sequentially Task picks up only the first few results and then fails because the termination message is truncated at 4KB and no longer valid JSON. Root cause Two facts combine: All step containers share one termination fil