.github: Add Automated release process #251
Conversation
corona10
commented
Dec 3, 2022
•
- Enable easier release process, we already use the same process for the pyperf releasing.
55a4b59 to
becbad4
Compare
|
@ericsnowcurrently PTAL :) |
292727f to
2f79b53
Compare
|
@hugovk |
There was a problem hiding this comment.
Thanks for doing this!
LGTM, with some recommendations and a few questions.
I'm not super familiar with the GitHub machinery, so it took me a little while to understand how the workflow maps onto the old steps. I've got it now, though. :) The workflow files seems correct, as far as I understood it.
I've left some suggestions about additional/updated comments (and maybe adding a template, if possible), but don't feel like those changes are necessary. On the one hand, the things I suggested would only really benefit the people with access to publish releases, who are probably already aware of all the information I suggested you explain. On the other hand, the extra information would probably benefit anyone who receives access to publish but hasn't ever done it before. (The info would also be useful for folks looking for examples of automated releases through GitHub, though that is more of a positive side effect than a good reason to add all the extra text, etc.)
(So feel free to merge without making any further changes in response to my suggestions, if you think that's okay.)
One other thing that came to mind is if there is any way to automate any of the rest of the release process (e.g. the "Prepare a release" steps)? What about having GitHub automatically fill in the version number (or even create the tag)?
Regardless of all my thoughts above, what you already have in this PR is a great improvement and a essential foundation for any additional improvements we might consider (though we'll already be better off even if we never make another change related to the release process after this.) FWIW, I'm certainly not expecting this PR to represent the final desired outcome.. 😄
| # - python -m build | ||
| # - twine upload dist/* | ||
| # - go to the GitHub release tab: https://github.com/python/pyperformance/releases | ||
| # - click "Draft a new release" and fill the contents |
There was a problem hiding this comment.
Do you mean "Create a new release"?
The URL is https://github.com/python/pyperformance/releases/new, right?
There was a problem hiding this comment.
Regarding "fill the contents", presumably you mean the following:
- select from "Choose a tag" dropdown (or "create a new tag" via that dropdown)
- select "Target: main" from the other dropdown (the default?)
- enter the version number for "Release title", matching the name of the tag from (1)
- enter something in "Describe this release"
Is the above correct?
Regarding (1), what's the best way to determine what the next version should be? It might be obvious to many, but it would help some if this were spelled out. Also, the tag should not exist yet right?
Regarding (4), what should go here? It seems like, at most, it would include either a basic "what's new" list or a link to a changelog. Leaving it blank would probably be fine too. Is there a way to have a template for this field (and maybe for (3) the "Release title" field?
Anyway, what you have is probably fine, but it may be worth putting a bit more info here in this comment in pyproject.toml.
There was a problem hiding this comment.
Also, am I correct in thinking that the "Prepare a release" steps remain unchanged?
If we can have a "publish" template, it would be nice if also reminded the person to make sure they completed those steps already.
There was a problem hiding this comment.
For (1), you can either pick an existing tag, or create a new one - the drop down box has "Find or create a new tag". Because we've not created one yet with these steps, we want to create a new one?
For (2) and (3), sounds good.
For (4), one option is to click the "Generate release notes" button and it'll fill something in based on the PRs that were merged.
| # - python -m build | ||
| # - twine upload dist/* | ||
| # - go to the GitHub release tab: https://github.com/python/pyperformance/releases | ||
| # - click "Draft a new release" and fill the contents |
There was a problem hiding this comment.
For (1), you can either pick an existing tag, or create a new one - the drop down box has "Find or create a new tag". Because we've not created one yet with these steps, we want to create a new one?
For (2) and (3), sounds good.
For (4), one option is to click the "Generate release notes" button and it'll fill something in based on the PRs that were merged.
Oh yes, there's a lot more automation possible! Here's roughly what I've set up for my projects (for example https://github.com/hugovk/norwegianblue/). For PRs, I have to add a "changelog: X" label, where X is one of the types of changes at https://keepachangelog.com/en/1.0.0/: Added, Changed, Deprecated, etc. For example: hugovk/norwegianblue#116 (I also have automation to ensure such a label has been added to a PR, and automation to add the labels to the repo in the first place.) Then, I'm using https://github.com/release-drafter/release-drafter to automatically draft a release. It runs when a PR is merged, and lists them by PR title (so I sometimes edit the PR title to make it a good release note title), and also groups them under each "changelog: X" category. For example: https://github.com/hugovk/norwegianblue/releases/tag/0.9.0 There are often PRs that don't touch production code, or that the end user doesn't care about (e.g. tests or config changes), and I label those with "changelog: skip" so they're left out from the notes. I have Release Drafter set up to follow SemVer: for bugs we just get a patch bump, for additions/changes we get a minor bump, and for removals we get a major bump. Also, when PRs are merged to https://github.com/hugovk/norwegianblue/blob/main/.github/workflows/deploy.yml#L46-L51 When I'm ready to release, I go to the release draft at https://github.com/hugovk/norwegianblue/releases. The draft is only shown to those with write access, until published, and currently looks like:
I edit the draft, check the version is good; I can change my mind and put another version if I want. I can also adjust what's listed if I want, change order, add/remove extra text etc. When happy, click "Publish release". This automatically adds the tag, creates the GH release, and kicks off the deploy to PyPI. I document the release process in https://github.com/hugovk/norwegianblue/blob/main/RELEASING.md so I have a good reference guide (in case another repo has slight variation). In short: add labels to PRs -> merge PR -> auto drafts release notes -> auto deploy to TestPyPI -> edit release -> publish release -> auto deploy to PyPI. |
Co-authored-by: Eric Snow <[email protected]>
Thanks for all your review! As same as @hugovk 's suggestion, |
|
Thanks for working on this, @corona10! It's a great improvement. |