Description of problem:

When a no-ops comment event is received from Forgejo/Gitea (e.g., a comment that doesn't match any pipeline trigger), Pipelines-as-Code attempts to resolve pipeline metadata and fails because there are no matching
PipelineRuns. The error handler then posts a failure comment on the pull request. That new comment triggers another webhook event from Forgejo, which is again a no-ops comment event, causing the same error and another
failure comment. This creates an infinite feedback loop of duplicate failure comments on the PR.

The root cause is in pkg/pipelineascode/match.go in the getPipelineRunsFromRepo function: when resolve.MetadataResolve returns an error and the pipeline run list is empty, the error is emitted as a comment via
eventEmitter.EmitMessage without checking whether the originating event was a no-ops comment. Since Forgejo/Gitea sends a new webhook for every comment posted on a PR (including PAC's own comments), this creates the
loop.

Prerequisites (if any, like setup, operators/versions):

• Pipelines-as-Code with Forgejo or Gitea as Git provider
• A repository with a .tekton/ directory containing PipelineRun definitions
• Webhook configured on Forgejo/Gitea pointing to PAC

Steps to Reproduce

Create a PR on a Forgejo/Gitea repository with PAC configured
Post a comment on the PR that does not match any pipeline trigger (a no-ops comment, e.g. a random comment or a bot comment)
Observe the PR comments and controller logs

Actual results:

PAC posts multiple duplicate failure comments on the PR. Each failure comment triggers a new webhook event, which generates another failure comment, creating a feedback loop. The PR gets flooded with identical error
comments such as:

found multiple pipelinerun in .tekton with the same name

(or any other MetadataResolve error)

Expected results:

PAC should post at most one failure comment. When the originating event is a no-ops comment event, MetadataResolve errors should be silently skipped (logged at info level only) to avoid creating a webhook feedback loop.

Reproducibility (Always/Intermittent/Only Once):

Always — occurs every time a no-ops comment event triggers a MetadataResolve error on Forgejo/Gitea.

Acceptance criteria:

• No-ops comment events that hit a MetadataResolve error do not post a failure comment
• The error is logged at info level for debugging purposes
• Only a single failure comment is posted per actual pipeline error (no duplicates from feedback loops)
• Existing behavior for non-comment events is unchanged
• E2E test validates that only one failure comment is posted after a no-ops comment triggers a metadata error

Definition of Done:

• Fix merged and passing CI
• E2E test (Gitea) confirms no duplicate comments
• No regression in other event types

Additional info (Such as Logs, Screenshots, etc):

The fix is in pkg/pipelineascode/match.go in the getPipelineRunsFromRepo function. Before emitting the error, check if the event type is a no-ops comment event (opscomments.NoOpsCommentEventType). If so, log the
error at info level and return nil, nil instead of posting a comment.

if p.event.EventType == opscomments.NoOpsCommentEventType.String() {
    p.logger.Infof("skipping MetadataResolve error for no-ops comment event: %s", err)
    return nil, nil
}