Story (Required)

As a Shipwright maintainer trying to support a stable release branch I want to be able to release the build and operator projects from a release branch.

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

We need to implement z-stream releases upstream for shipwright repositories

Out of scope

<Defines what is not included in this story>

• Draft the release branch strategy
• Cutting a z-stream release upstream - we should at least trial the release process

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 GitHub action that can create a tag on an input release branch. This should merge to the `main` branch, and use "workflow_dispatch" as its trigger.
• Update GitHub workflows (`.github/workflows`) in repository so events that trigger on the `main` branch also trigger on `release-v*` branches. See Github Workflows Syntax for more information.
• Create the release branch GitHub workflow from the "release branch" starter workflow (see SHIP-0038). This may need to be done by someone with "Write" permissions on the repository.
• Run the release branch workflow with the `v0.12` as the branch name an `v0.12.0` as the input git reference. This must be done by someone with "Write" permissions on the repository.
• Update GitHub workflows (`.github/workflows`) in the release branch so events that trigger on the `main` branch also trigger on `release-v*` branches. See Github Workflows Syntax for more information.

Dependencies

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

• BUILD-785 - agreement upstream on release branch strategy
• Shared workflow for creating release branches.

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>

• Respective repository (see title) has release branch defined
• Respective repository release branch is capable of running upstream CI checks
• Respective repository release branch "trail runs" a z-stream release.

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