Open nerrad opened 4 years ago
Looks like I could used marked to create a tree from the markdown of a pull request description and use that to detect if checkbox items we listen to are checked. These could be used to trigger various stages of the release process!
For safety, will need to limit automation actions to users that have the capabilities in the repo.
A variation of this script by @senadir could be used to automatically append bundlesize comparisons to the release pull request.
This is a tracking issue for automating release pull requests.
What is a release pull request?
In the Woo Blocks project we are implementing a process that is intended to streamline how we do releases so that they are covered by a checklist of items needing done before merging. This also will assist with potentially establishing a convention for other Woo teams to model.
A "release pull request" is a significant part of this process that documents all that needs to be done before a release tag can be generated and released. You can see examples here.
Things to automate
Here's a shortlist of some of the things I think could be built into the automation for this release process:
.github
folder and fallback to a default.release
in the branch? Likely something that could eventually be an option.release/{milestone}
should be the format of the branch name, and the {milestone} should correspond to a GitHub milestone that has all the work being released.@wordpress/changelog
and add that to the pull request description as well as modify the readme.txt. Then, commit to the branch.Along with the above, here's some additional things to consider:
type: release
label, but maybe there'd be additional labels that could be added?