Irrelevant tracing labels hardcoded into configuration

Hi folks.

I recently discovered PaC has explicit labels in its OTEL traces application, component, and action. These are somewhat confusing because they appear to be unrelated to any Pipelines as Code or Tekton model.

Background

The application, component, and action labels are pulled from the pipelinerun's labels delivery.tekton.dev/* which is not a meaningful or defined namespace in Tekton. These labels appear to be coming from konflux-ci's model, which builds on top of PaC. I don't think these labels belong in Pipelines as Code since they have no relation to TektonCD; they are downstream abstractions which were included based on the argument that the labels were "concepts that any platform can set on its PipelineRuns."

I'd like to remove the labels, however they clearly represent a valid need. Configuring custom trace attributes based on PipelineRun labels enables downstream consumers to better organize their tracing. And since PaC is the entry point a PipelineRun and creates the root OTEL trace, it is the ideal place to configure custom trace attributes.

Proposal

We can enable custom labels without hardcoding whatever downstream consumers want to bike-shed using simple namespacing in the configuration. Additionally, if the downstream consumers like Konflux have different domain models or need additional labels, a more flexible configuration enables them to add their own labels/attributes without hardcoding them upstream.

1. Remove references to delivery.tekton.dev/action, delivery.tekton.dev/application, and delivery.tekton.dev/component
2. Define a new configuration setting via regex, custom-tracing-label.([a-z_./-]+) (custom-tracing-label.<key>) where the key capture-group is the custom tracing attribute's key and the setting's value is the pipelineRun label where the value is pulled from. For example parity with the current behaviour would be to configure like so:

custom-tracing-label.cicd.pipeline.action.name: "delivery.tekton.dev/action"
custom-tracing-label.delivery.tekton.dev.application: "delivery.tekton.dev/application"
custom-tracing-label.delivery.tekton.dev.component: "delivery.tekton.dev/component"

3. (optional) Define a new configuration setting custom-tracing-label-domain which would simplify the configuration. E.g. the below would map the PLR label delivery.tekton.dev/action to the OTEL attribute cicd.pipeline.tekton.dev.action.name

custom-tracing-label-domain: "cicd.pipeline.tekton.dev"
custom-tracing-label.action.name: "delivery.tekton.dev/action"  
custom-tracing-label.application: "delivery.tekton.dev/application"
custom-tracing-label.component: "delivery.tekton.dev/component"

Backwards compatibility

A few points regarding the backwards compatibility of the change

• The attributes were added by Konflux-CI developers
• Their documentation was never published (#2902)
• No other (open source) project appears to reference these labels besides Konflux: GH search for delivery.tekton.dev
• Konflux-CI seems to change the delivery.tekton.dev labels to come from appstudio.openshift.io anyway: https://github.com/redhat-appstudio/infra-deployments/pull/13238

Start by locating the OpenTelemetry tracing configuration and the code that reads PipelineRun labels for the existing application, component, and action attributes. Remove the hardcoded references and add the proposed namespaced custom-tracing-label configuration, preserving configurable mappings and covering the behavior with tests. Done means downstream consumers can configure custom attributes without upstream hardcoded labels.