Story (Required)

As a service provider trying to use Pipelines as Code across multiple clusters I want Pipelines as Code to not send any messages to source repositories if it does not find a Repository CR.

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer's experience?>

Background (Required)

StoneSoup deploys Pipelines as Code across multiple clusters. As a "hack", the StoneSoup team implemented a simple proxy that broadcasts incoming webhooks (GitHub) to each registered cluster running Pipelines as Code.

This results in a poor user experience, especially with GitHub's Checks API. The check results will initially report "Skipped", only to later report success/failure. Even then, this can be inconsistent depending on browser caching used by GitHub.

<Describes the context or background related to this story>

Out of scope

<Defines what is not included in this story>

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• Pipelines as Code can be configured to not send messages/Checks API requests if a Repository is not found for a given incoming request.
• When this configuration is enabled, Pipelines as Code does not send a message to an SCM provider if an incoming request does not have a corresponding Repository CR.

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

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