New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GH action for release PR & checklist #56
Conversation
7eed2e4
to
0e29cbd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I think this will continue to be a process to iterate on, but we aren't going to do that until we merge it and start using it.
I left a few comments but they aren't blockers as we should start the adoption and improve as we go along.
1. [ ] Run a few basic smoke tests | ||
|
||
## Next steps | ||
1. ~Approve this PR to allow the next workflow to create an actual release.~ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, which workflow is this pointing to? Or is this still something we need to create?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something to be implemented, see #56 (comment)
When prompted for changelog entries, double-check and apply any changes if needed. | ||
1. ~Another workflow will pick up the new release and post a comment here with GitHub's release notes, merge the PR, and merge \`trunk\` to \`develop\`.~ | ||
1. [ ] Go to ${ context.payload.repository.html_url }/releases/${ version }, generate GitHub release notes, and paste them as a comment here. | ||
1. [ ] Merge this PR after the new release is successfully created and the version tags are updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In two steps above this one we mention that a workflow will run to merge the PR and merge trunk to develop. Yet here it mentions to merge the PR but doesn't mention to merge trunk to develop. From what I understand the workflow hasn't been created yet, but until then can we mention all the manual steps that are needed. Or clarify what needs to be done here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created strike-through items to keep an eye on workflows to be implemented, mostly because I was planning to do at least some of them within HACK day. But I'll remove them as it seems they introduce more confusion than value :)
to reduce confusion. These were to be implemented ideas. Add manual next stepto merge `trunk` to `develop`. Addresses #56 (comment)
This is a continuation of https://github.com/woocommerce/automatewoo/pull/1404
Changes proposed in this Pull Request:
Adds a new GitHub Action to prepare extension release.
To be used with a manual GH workflow. It takes versions, then starts a branch and creates a PR with the checklist.
The aim is to automate and unify the release process across our repos.
Screenshots:
Detailed test instructions:
Add a workflow in another repo following the instructions from
packages/js/github-actions/actions/prepare-extension-release/README.md
, replacingwoocommerce/grow/prepare-extension-release@actions-v1
withwoocommerce/grow/prepare-extension-release@actions-v1.5.2-pre
as this PR is not yet released.Like https://github.com/tomalec/grow/blob/391113cd2a00bac2dc808674ecebdb30e8fd83da/.github/workflows/extension-release.yml
Run the created workflow.
Additional details:
The further improvements automation I was trying to implement but didn't finish:
woorelease simulate
. So we could reduce two more manual steps for the developer, and serve them just a.zip
package to smoke test & changelog to inspect. It's tricky, as requires setting up all woorelease keys on GHA, and makes the simulation repo harder to inspect.trunk
trunk
todevelop
Further improvements I envision:
major|minor|patch
instead of typing a full versionChangelog entry