Story (Required)

As a Pipeline User using Pipelines-as-Code (PAC), when a Pull Request is merged while its associated PipelineRun is still running, I want the running PipelineRun not to be cancelled unexpectedly, unless I have explicitly configured the `pipelinesascode.tekton.dev/cancel-in-progress: "true"` annotation.

This story addresses a bug where running PAC PipelineRuns are incorrectly cancelled upon PR merge even when the opt-in cancellation feature is not enabled. Fixing this ensures predictable pipeline execution and aligns the behaviour with the documented feature, improving the user experience by preventing unexpected pipeline terminations.

Background (Required)

In OpenShift Pipelines v1.18 / Pipelines-as-Code (PAC), a Technology Preview feature was introduced allowing users to automatically cancel an in-progress PipelineRun when a new one is triggered for the same context (e.g., same PR after a new commit). This is enabled via the `pipelinesascode.tekton.dev/cancel-in-progress: "true"` annotation.

A customer reported an issue where, even without this annotation being set, if a Pull Request (PR) is merged while a corresponding PipelineRun is running, that PipelineRun gets cancelled. This is unexpected behaviour.

Interestingly, the report notes that if a PipelineRun is in a pending state when the PR is merged, it does not get cancelled.
.

Out of scope

• Changing the intended behaviour of the `pipelinesascode.tekton.dev/cancel-in-progress: "true"` annotation when it is set.
• Addressing the behaviour of pending PipelineRuns upon PR merge (as they are reportedly not being cancelled).
• Fixing the unrelated bug mentioned (#04109573).
• Changing the Technology Preview status of the `cancel-in-progress` feature itself.

Approach (Required)

Investigate the Pipelines-as-Code controller logic responsible for handling webhook events, specifically events related to Pull Request merges (`pull_request` event with `action: closed` and `merged: true`, or similar).
The logic needs to be updated to explicitly check for the presence and value of the `pipelinesascode.tekton.dev/cancel-in-progress` annotation on the relevant resource (e.g., Repository CR or PipelineRun) before initiating a cancellation of an existing PipelineRun triggered by a PR merge event.
If the annotation is not present or set to `"false"`, the cancellation step for running pipelines triggered by the merge event should be skipped.

Dependencies

• Requires understanding of PAC event handling and Tekton PipelineRun cancellation mechanisms.
• Targeted for inclusion in the OpenShift Pipelines v1.18.1 patch release.

Acceptance Criteria (Mandatory)

• GIVEN a PAC-managed Repository exists
• AND the `pipelinesascode.tekton.dev/cancel-in-progress` annotation is NOT set to `"true"` on the Repository CR or relevant PipelineRun
• AND a PipelineRun is RUNNING for an open Pull Request
• WHEN the Pull Request is merged
• THEN the running PipelineRun should NOT be cancelled by PAC due to the merge event and should continue execution.

• GIVEN a PAC-managed Repository exists
• AND the `pipelinesascode.tekton.dev/cancel-in-progress` annotation IS set to `"true"` on the Repository CR or relevant PipelineRun
• AND a PipelineRun (`PR-run-1`) is RUNNING for an open Pull Request
• WHEN a new event triggers a new PipelineRun (`PR-run-2`) for the same context (e.g. new commit to the PR)
• THEN the original running PipelineRun (`PR-run-1`) SHOULD be cancelled as per the feature's intended behaviour. (Verification that the fix doesn't break the intended feature)

INVEST Checklist

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

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