Story (Required)

As a Red hat engineer trying to release Builds for OpenShift I want Konflux to run an end to end test of the Shared Resource CSI Driver.

<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)

<Describes the context or background related to this story>

• Konflux supports running "integration" tests using a temporary "environment."
• We currently have no means of ensuring our operator bundle deploys every component correctly.

Out of scope

<Defines what is not included in this story>

• Business logic/e2e testing of each component. Goal is to ensure that all components can at least deploy.
• Upstream tests

Approach (Required)

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

• Konflux provisions an empty Kubernetes/OpenShift cluster. Note: this cluster should not have any extra operators installed!
• Create a set of "smoke" e2 tests that do the following:
  • Deploys the OpenShift Pipelines Operator in a setup phase
  • Deploys the candidate Builds for OpenShift operator bundle
  • Runs a test verifying all shipwright components are deployed and ready
  • Runs a test verifying all Shared Resource components are deployed and ready

Dependencies

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

• Shipwright components onboarded to Konflux
• Shared resources components onboarded to Konflux
• Operator deploys Shipwright and Shared Resources

Acceptance Criteria (Mandatory)

<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>

• Konflux integration test set up for builds operator
• Integration test deploys a temporary OpenShift cluster
• Integration test verifies a candidate operator bundle can be deployed.
• Integration test verifies our operands are deployed and ready/available.

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