Skip to content
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

Merged
merged 4 commits into from May 30, 2023
Merged

Add GH action for release PR & checklist #56

merged 4 commits into from May 30, 2023

Conversation

tomalec
Copy link
Member

@tomalec tomalec commented May 25, 2023

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:

image

Detailed test instructions:

  1. Add a workflow in another repo following the instructions from packages/js/github-actions/actions/prepare-extension-release/README.md, replacing woocommerce/grow/prepare-extension-release@actions-v1 with woocommerce/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

  2. Run the created workflow.

Additional details:

The further improvements automation I was trying to implement but didn't finish:

  1. (tricky) Make the workflow run 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.
  2. (tricky) Make another workflow pick up the approval, and make the actual release. The tricky part is as above. But it may mitigate a few more issues we were experiencing in the past, as it could assert the consistent build environment (node, npm, composer versions)
  3. (easier) Make another workflow pick up a release, then
    1. publish the GitHub's release notes as a comment to matching PR,
    2. merge the PR to trunk
    3. merge trunk to develop

Further improvements I envision:

  1. Allow bumping version by just major|minor|patch instead of typing a full version
  2. Allow customizing checklist, so some repos could have a few more specific steps

Changelog entry

Add - Extension release preparation github-action.

@tomalec tomalec force-pushed the add/release-pr branch 2 times, most recently from 7eed2e4 to 0e29cbd Compare May 25, 2023 13:33
@tomalec tomalec marked this pull request as ready for review May 29, 2023 12:58
@tomalec tomalec self-assigned this May 29, 2023
Copy link
Contributor

@mikkamp mikkamp left a 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.~
Copy link
Contributor

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?

Copy link
Member Author

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.
Copy link
Contributor

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.

Copy link
Member Author

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)
@tomalec tomalec merged commit 482dd17 into trunk May 30, 2023
2 checks passed
@tomalec tomalec deleted the add/release-pr branch May 30, 2023 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants