As a Pipeline Service developer consuming OSP nightly builds (OSP v5.0) I want verification of those builds using automated smoke test with results of the test reported to UMB.

Background (Required)

The OSP builds used in Pipeline Service are tested in the Pipeline Service CI and later in Konflux. Ideally the builds will be tested earlier, right/soon after the Build pipeline finishes building the product. The OSP QE team have the knowledge and experience to keep the tests up-to-date and investigate and report the failures.

Out of scope

<Defines what is not included in this story>

Approach (Required)

The proposed flow includes the following steps:

1. The CPaaS Build pipeline creates new version for the product
2. UMB message is emitted including information about successful builds marked as smoke-test-trigger in the product config (e.g https://gitlab.cee.redhat.com/cpaas-products/openshift-pipelines/-/blob/main/versions/release-5.0.5/product.yml?ref_type=heads#L100). Information about the configuration and message format can be found here: https://cpaas.pages.redhat.com/documentation/how-to/trigger-external-jenkins-jobs.html . There is an alternative option where the smoke tests are triggered after the CVP tests, again using an UMB message with a different format (https://cpaas.pages.redhat.com/documentation/users/gating/using_gating_in_cpaas.html#_container_verification_pipeline_cvp)
3. The smoke tests are executed and UMB message emitted with the test result. Information about the topic and message format https://cpaas.pages.redhat.com/documentation/users/update_resultsDB.html

Dependencies

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

Acceptance Criteria (Mandatory)

1. Smoke tests are automatically triggered for new OSP nightly builds (v5.0)
2. UMB message with the operator bundle NVR and test result are sent to UMB

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