-
Story
-
Resolution: Done
-
Critical
-
builds-1.0
-
1
-
False
-
None
-
False
-
SECFLOWOTL-24 - Openshift Builds (Shipwright) : GA v1.0
-
-
-
3
-
Pipeline Integrations #3254
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>
- 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- Creation of the starter workflow and shared GitHub action workflow for release branching. See
BUILD-894
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
- depends on
-
BUILD-785 SPIKE: Upstream release branch strategy
- Closed
-
BUILD-894 Create shared GitHub workflow for release branching
- Closed
- is blocked by
-
BUILD-785 SPIKE: Upstream release branch strategy
- Closed
-
BUILD-894 Create shared GitHub workflow for release branching
- Closed
- is cloned by
-
BUILD-852 Implement release branch strategy for shipwright-io/operator
- Closed
-
BUILD-853 Implement release branch strategy for shipwright-io/cli
- Closed
- links to