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 cluster admin trying to deploy the latest Shipwright I want to use the operator to deploy a more recent nightly build (2023-08-29) that does not include the v1beta1 conversion webhooks.

Background (Required)

<Describes the context or background related to this story>

The Shipwright operator upstream currently deploys the v0.11.0 release of Shipwright Build. To get ready to deploy the webhook components, we should first update the `release.yaml` with a more recent nightly release that does not include the v1beta1 conversion webhook, and fix any issues related to this incremental update.

Out of scope

<Defines what is not included in this story>

• Upgrade the operator to deploy the conversion webhook and related certificate authorities
• Upgrade operator-sdk
• Address any feature requests related to status reporting.

Approach (Required)

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

1. Update kodata/release.yaml with a recent nightly build (2028-08-29 for reference).
2. Conduct any refactorings/upgrades necessary to ensure the operator functions properly under normal circumstances.
3. Regenerate the bundle (the Makefile has a target which does this).

Dependencies

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

• None expected.

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>

1. Operator is able to deploy a more recent nightly build that does serve the v1beta1 API or include admission webhooks.
2. CI tests upstream pass

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