/retest falls back to re-running all pipelines when pipelineruns have been pruned

[chmouel]

Bug Description

The /retest command was fixed in PR #2048 (commit cd437c52a) to skip already-green pipelines (SRVKP-7236). However, this fix only works when the original PipelineRun objects still exist in the Kubernetes cluster.

When PipelineRuns are pruned — either by max-keep-runs or by Tekton Results pruner — /retest silently falls back to re-running all pipelines, defeating the purpose of the fix.

Steps to Reproduce

1. Configure a repository with multiple pipelines (e.g., lint, test, build)
2. Push a commit — all three pipelines run, lint and build succeed, test fails
3. Wait for PipelineRuns to be pruned (via max-keep-runs or Tekton Results pruner)
4. Comment /retest on the PR
5. Expected: Only test is re-run (since lint and build succeeded)
6. Actual: All three pipelines are re-run

Root Cause

In pkg/matcher/annotation_matcher.go:441-498, filterSuccessfulTemplates():

1. Queries Kubernetes for PipelineRuns matching the SHA label (lines 447-450)
2. When the query succeeds but returns 0 results (PipelineRuns pruned), the successfulTemplates map is empty
3. All templates pass through the filter → all pipelines re-run
4. There is no fallback to check Repository.Status (which persists after pruning)

Possible Solution Direction

Use Repository.Status as a fallback when no PipelineRuns are found in the cluster. This would require:

1. Adding an OriginalPRName field (template name) to RepositoryRunStatus (pkg/apis/pipelinesascode/v1alpha1/types.go:28) so that status entries can be matched back to pipeline templates
2. Updating filterSuccessfulTemplates() to consult Repository.Status when the Kubernetes PipelineRun query returns empty results

Note: RepositoryRunStatus is currently limited to 5 entries (maxPipelineRunStatusRun in pkg/reconciler/status.go:28), which may need consideration depending on the number of pipelines configured.

Additional Context

• Original fix: PR fix: /ok-to-test /retest pipelineruns should not be created if last sha successful #2048, SRVKP-7236
• Identified by Andrew Thorp in Jira comments on SRVKP-7236