perf: strip documentation-only fields from resolved status snapshots

Feature request

Strip description fields from params, workspaces, and results when copying resolved specs into status.taskSpec and status.pipelineSpec.

Problem

When Tekton resolves a Task or Pipeline, it snapshots the full spec into the object's status (status.taskSpec, status.pipelineSpec). This snapshot includes description fields on params, workspaces, and results — fields that are purely informational and never read by the controller during execution.

These description fields are copied into every revision of the object in etcd. Since etcd stores full object copies per revision (not diffs), and a TaskRun may accumulate 10-20 revisions during its lifecycle, the overhead is multiplied significantly.

Impact

The actual savings depend on how verbose the task/pipeline descriptions are. Some examples:

tektoncd/catalog (475 tasks/stepactions):

• 15.8% of total spec size is descriptions
• 65% of objects have >5% description overhead
• Highest: git-batch-merge (30%), git-clone (21-28%), buildpacks-phases (15%)

konflux-ci/build-definitions (176 tasks/pipelines):

• 8.3% of total spec size is descriptions (lower ratio because tasks contain large inline scripts)
• 63% of objects have >5% description overhead
• Highest: ecosystem-cert-preflight-checks (36%), buildah variants (7-14%)

The key insight is that these bytes are amplified by revision count. A TaskRun with 10-20 revisions stores 10-20 full copies of the object. So 5 KB of descriptions becomes 50-100 KB of etcd storage per TaskRun. At scale (e.g., 300 concurrent PipelineRuns × 20 TaskRuns each), this adds up to hundreds of MB of etcd space used purely for documentation strings.

Proposed change

During task/pipeline resolution, when populating status.taskSpec / status.pipelineSpec, strip the description field from:

• params[*].description
• workspaces[*].description
• results[*].description
• Any other spec-level fields carrying description purely for documentation

The original Task/Pipeline objects retain their descriptions — only the resolved snapshot in status is stripped.

Why this is safe

• The controller reads exclusively from status.taskSpec / status.pipelineSpec for execution
• It never uses description fields for any runtime decision
• These fields exist solely for UI display and human documentation, so we just need to verify that clients like the cli and dashboard do not rely on those status spec fields.
• The original Task/Pipeline objects retain their descriptions for anyone who needs them

Fields to audit

A full audit should identify all description-carrying fields in the resolved spec. Known candidates:

• spec.params[*].description (ParamSpec)
• spec.workspaces[*].description (WorkspaceDeclaration)
• spec.results[*].description (TaskResult / PipelineResult)
• Any nested descriptions in step or sidecar specs

Related

• #9573 — strip managedFields from informer caches (addresses controller memory, not etcd size)