Story (Required)

As a PaC user/developer trying to control when PaC pipelines are triggered, I want to be able to include a specific tag in my git commit message so that PaC skips running pipelines for that commit.

This story aims to provide PaC users with a simple, commit-message-based mechanism to prevent pipeline runs for specific commits. It addresses a user need for more granular control over CI execution, similar to features found in other CI systems, improving the developer experience by avoiding unnecessary pipeline runs for minor or "work-in-progress" commits.

Background (Required)

Currently, PaC does not offer a direct mechanism to skip pipeline runs based on a tag within a git commit message. Users, such as Lui, have expressed a need for this feature. While other methods like CEL expressions exist, a simple commit message tag (e.g., `[skip ci]`) is a common and intuitive feature in many CI/CD systems, including Prow and GitHub Actions. This feature would align PaC with common CI/CD practices and provide a straightforward way for developers to manage pipeline execution.

—

Out of scope

• Implementing new CEL expression capabilities (existing CEL expressions for filtering/skipping are not part of this story).
• Developing other forms of pipeline skipping (e.g., based on file changes, branch names, specific paths, etc.) unless directly leveraging the commit message content.
• Making the skip tag fully configurable via PaC resources in the initial iteration (focus will be on a fixed, well-documented tag).

—

Approach (Required)

The general technical path involves modifying PaC's event processing logic to inspect incoming git commit messages.
1. *Define Skip Keyword:* Establish a specific keyword or phrase (e.g., `[skip ci]`) that, when present in a commit message, signals PaC to skip pipeline execution.
2. *Commit Message Parsing:* Enhance the PaC event listener or trigger component to parse the commit message associated with a push event.
3. *Conditional Triggering:* Introduce a check: if the defined skip keyword is found within the commit message, prevent the creation of a `PipelineRun` resource for that specific event.
4. *Normal Flow:* If the skip keyword is not found, proceed with the standard `PipelineRun` creation process.

Consideration should be given to where this parsing and blocking logic best resides within the PaC architecture (e.g., in the controller handling `GitOpsConfig` or `Repository` resources, or within a specific event handler).

—

Dependencies

• Existing PaC event processing mechanisms and `PipelineRun` creation logic.

—

Acceptance Criteria (Mandatory)

• Given a git commit message contains the specified skip keyword (e.g., `[skip ci]`), when the commit is pushed, then PaC MUST NOT create a `PipelineRun` for that commit.
• Given a git commit message does NOT contain the specified skip keyword, when the commit is pushed, then PaC MUST create a `PipelineRun` as it would normally.
• The chosen skip keyword (e.g., `[skip ci]`) must be clearly documented in PaC's user guide or relevant developer documentation.
• The skipping mechanism should be applied to all relevant PaC trigger types that process commit messages (e.g., push events).
• The check for the skip keyword should be case-insensitive (e.g., `[skip ci]`, `[SKIP CI]`, `[Skip CI]` should all trigger the skip).

—

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