SHIP-0038: Implementable Version #194
Conversation
This updates SHIP-0038 with sufficient details to mark it "implementable." The proposal now contains specific details on how to use starter and reusable GitHub Action workflows to implement release branching across all component repos. Security requirements such as branch protection are fully outlined, and a process for backporting using the Prow cherrypick bot is described. This proposal attempts to minimize changes to existing release workflows. Adopting a more uniform toolkit like GoReleaser would add scope and discourage future attempts to "dogfood" Shipwright. Ideally Shipwright is able to build and release itself, however this imposes real infrastructure costs the project is not able to fund at present. Other alternatives are articulated in the proposal as well. Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
pull-request-size
bot
added
the
size/L
|
/assign @SaschaSchwarze0 /cc @apoorvajagtap |
- Example YAMLs do not have valid GitHub Actions schema. - Fix referenced file location for reusable workflows. Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
There was a problem hiding this comment.
Only small things. Mostly ready to approve. We will also need to update our release how to (https://hackmd.io/OMxlKFgaSsGEsO5TaQgieg).
| We can craete a reusable "release branching" workflow [2] as follows: | ||
|
|
||
| - Use `workflow_call` as the trigger, to be run on the main branch. [2] | ||
| - Receive a semantic version as input, to then create the release branch name. |
There was a problem hiding this comment.
| - Receive a semantic version as input, to then create the release branch name. | |
| - Receive a semantic version as input which must be a `vX.Y.0` tag, to then create the release branch name. |
There was a problem hiding this comment.
In my PoC testing, it made sense to leave the semantic version as vX.Y format, and omit the trailing .0. I added a description to that effect, which shows up in the GitHub UI (per the example YAML below).
| However, each will need to be modified so the release workflow runs against the | ||
| appropriate `release-vX.Y` branch: | ||
|
|
||
| - `build`: The `release.yml` workflow will receive a new required parameter, |
There was a problem hiding this comment.
Fo build, we will get a PR that updates the readme. This PR we either simply manually fix, or we must extend the logic. I guess by default it would modify the readme from the current branch and open the PR against main. This will probably not be mergable.
There was a problem hiding this comment.
👍 - I'll add a comment that this workflow will need to be modified to open the PR against the release branch.
There was a problem hiding this comment.
Looking at the action doc [1], the base parameter can be used to specify the PR base branch, and it defaults to "the branch checked out in the workflow." So you could have some temporary skew between the release branch and main if leave it as is (or set main to always reference the "latest" release).
[1] https://github.com/marketplace/actions/create-pull-request
There was a problem hiding this comment.
Well, the readme update with the new tag, we would want it in main?
There was a problem hiding this comment.
Looking at the README today, our install instructions reference the release by explicit version number, and it is published against main.
|
|
||
| #### GitHub Branch Protection | ||
|
|
||
| Each repository will need to create a new branch protection rule that applies to |
There was a problem hiding this comment.
I still fear we will need a dedicated branch protection rule and cannot use wildcards in the branch name due to the different matrix values in e2e/integration tests. But, we can simply see what happens and adjust.
There was a problem hiding this comment.
I still fear we will need a dedicated branch protection rule
As in we would need individual branch protection rules for each branch name? That would be a more significant drawback than I thought.
| 1. "Manually": this would involve a contributor running `git cherry-pick` on their | ||
| local machine against a release branch, resolving any merge conflicts, then | ||
| opening a pull request | ||
| 2. Prow `cherrypick` bot: our existing configuration for OpenShift CI will be | ||
| updated to enable the Prow cherrypick plugin. The bot can automatically create | ||
| cherrypick pull requests by adding a `/cherrypick <branch-name>` comment to an | ||
| existing pull request, either when it is open or after merge. See the Prow | ||
| docs [1] for more details. |
There was a problem hiding this comment.
I assume that for things like go.mod updates, cherry-picks will not work well unless this bot has intelligence (=only picks the go.mod change and then runs go mod tidy and go mod vendor). So, a "contributor creating a new commit with the same solution just for this branch" would also be allowed.
There was a problem hiding this comment.
👍 - dependency updates have a much higher likelihood of having merge conflicts when cherrypicking.
I'll clarify that this process should be reserved for bug fixes.
🤔 need to check if Dependabot can be configured to run on the release branches.
Adding spell checks and clarification from @SaschaSchwarze0 Co-authored-by: Sascha Schwarze <schwarzs@de.ibm.com>
- Clarify inputs to the release brancher process. - Update backport process to include "standard pull request" option. Cherrypicking is not always an option, especially for dependency updates.
|
@SaschaSchwarze0 @qu1queee please take at this SHIP and its related PR to set up the release branch starter/shared workflow: shipwright-io/.github#3 I'd like to have everything in place so we can start backporting the go-git CVE fix in shipwright-io/build to v0.12 next week. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SaschaSchwarze0 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Changes
This updates SHIP-0038 with sufficient details to mark it "implementable." The proposal now contains specific details on how to use starter and reusable GitHub Action workflows to implement release branching across all component repos. Security requirements such as branch protection are fully outlined, and a process for backporting using the Prow cherrypick bot is described.
This proposal attempts to minimize changes to existing release workflows. Adopting a more uniform toolkit like GoReleaser would add scope and discourage future attempts to "dogfood" Shipwright. Ideally Shipwright is able to build and release itself, however this imposes real infrastructure costs the project is not able to fund at present.
Other alternatives are articulated in the proposal as well.
Related to #85.
Follows up on #190.
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes