Story (Required)

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

As a Shipwright maintainer trying to keep the operator up to date I want nightly releases of shipwright-io/build to be submitted to shipwright-io/operator as a pull request.

Background (Required)

<Describes the context or background related to this story>

The shipwright-io/build project has a nightly release containing the latest release.yaml manifest. The operator historically has not received these incremental updates via pull request, leading to a "mad dash" when the operator wants to update release.yaml to include the latest build release.

We should contribute a script to shipwright-io/operator which finds the most recent `release.yaml` from the nightly release and updates the manifest in the kodata folder. Future contributors can then simply run a script to update release.yaml and test the upcoming release of the build controller.

Out of scope

<Defines what is not included in this story>

• Automating the `release.yaml` update via GitHub actions. This can be taken up as a follow-up story.
• Download `release.yaml` from a proper tagged release, not nightly. This can be taken up as a follow-up story.
• Sync the build strategies in the `samples.yaml`. The operator uses a different folder structure to sync sample strategies.
• Sync the "debug" version of the manifests - this is not deployed by the operator.

Approach (Required)

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

• Create a script in the Operator repo to create PR with the updated release.yaml.

Dependencies

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

• Nightly release process for shipwright-io/build.
• Means to view release assets in a command line/script. The `gh` command line can do this.

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>

• Script that can update `release.yaml` with latest "nightly" changes is contributed to shipwright-io/operator
• Script can be invoked via a `make` target
• Operator deploys new version of the build controller when `release.yaml` is updated.

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