Story (Required)

As a Konflux Platform Engineer, I want Pipelines as Code (PaC) to only parse and report errors for Tekton PipelineRun resources, so that users are not confused by false-positive error comments on unrelated YAML files in their `.tekton` directory.

The current PaC implementation attempts to parse every YAML file in the `.tekton` directory, causing it to incorrectly flag valid, non-Tekton resources (like `ImageDigestMirrorSet`) as errors. This creates unnecessary noise on pull requests, erodes user trust in the CI system, and generates confusing support requests. The desired outcome is for PaC to be more precise and only validate files that are explicitly Tekton PipelineRuns.

Background (Required)

A recent update to Pipelines as Code (PaC) enabled a feature to comment on Pull Requests when it encounters an issue parsing a resource. This has revealed that PaC is attempting to parse all YAML files within the `.tekton/` directory as Tekton resources, which is not always the case.

Users are now seeing incorrect error comments on their PRs for any valid Kubernetes resource that is not a PipelineRun. The most common example is the `ImageDigestMirrorSet` resource, which is required for certain tasks and co-located in the `.tekton` directory.

The error comment typically looks like this:

no kind "ImageDigestMirrorSet" is registered for version "operator.openshift.io/v1alpha1" in scheme "k8s.io/client-go/kubernetes/scheme/register.go:83"

While this error is benign and the actual CI jobs succeed, it is causing significant confusion. The core of the issue is that PaC should not be attempting to parse files that are not Tekton PipelineRuns.

Examples of affected PRs:

• https://github.com/openshift-kni/lifecycle-agent/pull/1248#issuecomment-2996756319
• https://github.com/stackrox/stackrox/pull/15583#issuecomment-2995596631

Out of scope

• This story is not about disabling the PaC error-commenting feature entirely.
• This story will not involve moving user files (like `ImageDigestMirrorSet`) out of the `.tekton` directory. The solution should adapt to the user's existing file structure.

Approach (Required)

The required approach is to make the PaC parsing logic more intelligent. PaC should inspect a YAML file before attempting a full parse and validation against the Tekton schema.

1. Pre-Parsing Check: Before sending a file to the Kubernetes client for validation, PaC should perform a lightweight check on the file's contents.
2. Selective Validation: PaC should only attempt to fully parse files that are identified as Tekton resources, for example by checking for `apiVersion: tekton.dev/v1beta1` (or `v1`) and `kind: PipelineRun`.
3. Graceful Skip: If a file does not match the Tekton PipelineRun `apiVersion` and `kind`, PaC should silently and gracefully skip it, assuming it is a configuration file for a different purpose.

This approach ensures that only relevant files are validated, eliminating the false-positive errors while keeping the valuable feedback mechanism for actual PipelineRun syntax issues.

Dependencies

• This issue was converted from the Konflux support ticket: https://issues.redhat.com/browse/KFLUXSPRT-3802
• Resolution depends on the ability to modify the Pipelines as Code (PaC) codebase.

Acceptance Criteria (Mandatory)

• Given a repository with a YAML file in the `.tekton/` directory that is not a Tekton PipelineRun (e.g., `ImageDigestMirrorSet`, a `ConfigMap`, etc.), when a pull request is created, Pipelines as Code must not post a parsing error comment for that file.
• Given a repository with a YAML file in the `.tekton/` directory that has an invalid or malformed Tekton `PipelineRun` definition, when a pull request is created, Pipelines as Code must still post a relevant error comment.
• The CI/CD pipelines that rely on the non-PipelineRun YAML files (like `fips-operator-bundle-check-oci-ta` using `ImageDigestMirrorSet`) must continue to function correctly.
• The fix is validated and does not cause regressions in PaC's ability to discover and run valid `PipelineRun` definitions.

INVEST Checklist

. Dependencies identified
. Blockers noted and expected delivery timelines set
. Design is implementable
. Acceptance criteria agreed upon
. Story estimated

Legend

. Unknown
. Verified
. Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met