Story (Required)

As a Pipeline as Code user trying to use the `/ok-to-test` and `/retest` commands I want to avoid creating redundant PipelineRuns if a successful run already exists for the same commit SHA.

This story addresses the issue of creating duplicate PipelineRuns when using the `/ok-to-test` and `/retest` commands. By preventing redundant runs, we improve efficiency and reduce unnecessary resource consumption. This improves the user experience by streamlining the process and making it more efficient.

Background (Required)

Currently, using `/ok-to-test` or `/retest` always creates a new PipelineRun, even if a previous run for the same SHA was successful. This leads to wasted resources and unnecessary pipeline executions. This issue aims to optimize the pipeline creation process by checking for existing successful runs before creating new ones.

Out of scope

Handling errors during the listing of existing PipelineRuns in a more sophisticated way beyond logging (e.g., retry mechanisms, alerting). Implementing this improvement for commands other than `/ok-to-test` and `/retest`.

Approach (Required)

The approach involves adding a new function, `checkForExistingSuccessfulPipelineRun`, that checks for existing PipelineRuns with the same SHA. This function will query the Kubernetes API to list PipelineRuns with a specific label selector. The latest successful PipelineRun (if any) will be identified and returned. The `MatchPipelinerunByAnnotation` function will be updated to utilize this new function, preventing the creation of a new PipelineRun if a successful one already exists. The solution is implemented in Go and integrates with the Tekton API.

Dependencies

None

Acceptance Criteria (Mandatory)

• Given a successful PipelineRun exists for a given SHA.
• When the `/ok-to-test` command is used for the same SHA.
• Then a new PipelineRun should not be created.
• Given a successful PipelineRun exists for a given SHA.
• When the `/retest` command is used for the same SHA.
• Then a new PipelineRun should not be created.
• Given a failed PipelineRun exists for a given SHA.
• When the `/ok-to-test` command is used for the same SHA.
• Then a new PipelineRun should be created.
• Given a failed PipelineRun exists for a given SHA.
• When the `/retest` command is used for the same SHA.
• Then a new PipelineRun should be created.
• The implementation includes logging for errors encountered during the listing of PipelineRuns.

INVEST Checklist

Dependencies identified: Verified
Blockers noted and expected delivery timelines set: Unsatisfied
Design is implementable: Verified
Acceptance criteria agreed upon: Unsatisfied
Story estimated: Unknown

Legend

Unknown
Verified
Unsatisfied

Done Checklist

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

Originial Pull Request number

https://github.com/openshift-pipelines/pipelines-as-code/pull/2048(https://github.com/openshift-pipelines/pipelines-as-code/pull/2048)

Original Pull Request Description

when executing /ok-to-test or /retest gitops commands, check whether the last pipelinerun created for the same SHA was successful. If the run was successful, skip new pipelinerun creation

fixes https://github.com/openshift-pipelines/pipelines-as-code/issues/1959