-
Notifications
You must be signed in to change notification settings - Fork 41
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
Automate release notes for minor releases #4859
Comments
Here's the PR: #4860 |
If/when this is merged, someone with admin access to this ( |
Thanks for working on this @BWPanda 🙏 |
Awesome, thanks @BWPanda! I'm not sure we need the wiki page component of it. IMO it will be sufficient for us to be able to download the asset ZIP from the build job (assuming that happens). Let's give a shot with the 1.18.0 milestone and see how it goes. I've merged the PR, though I'm leaving this open because I think we'll likely need further adjustments. |
Wow, it works! I closed the 1.18.0 milestone and it made this nice wiki page! https://github.com/backdrop/backdrop-issues/wiki/1.18.0 Picture for posterity in the event we remove this page: I really like how it can automatically map our labels to particular categories like "Bug fixes" vs "Features". Apparently it can also generate a list of "contributors" based on the people involved in the issues! Very neat. I'm not sure this is the best use of the Wiki however. We could take a few options from here:
For the time being, I'm leaning towards the second approach. Even if we start using the GitHub wiki more extensively, I am not sure that putting the release notes in it is really helpful for our users. We may end up with people starting to link to both the release note Wiki pages and the Release pages (onto which we copy release notes). I think we'd prefer to just have them in one place. |
@quicksketch Glad it worked! 🎉 I like the idea of moving the procedural docs to the wiki, but I'll leave that for a separate issue. And I agree that having release notes in two places isn't ideal, so I've gone ahead and changed the action to upload the notes as an artifact instead. I closed (and re-opened the milestone) and here's the result: https://github.com/backdrop/backdrop-issues/actions/runs/465228286 That link allows you to download a zip file that has the release node markdown file in it. |
So if you're happy with this solution, you can:
|
Super! I'll delete that token since I feel it's good to be tidy about such things. This is a great solution and will save us hours of work every single release. Thanks so much @BWPanda! |
@quicksketch asked me to look into a better system of automatically generating release notes when a minor release is published. Currently
drush rn
is used, but it includes a bunch of commits that aren't relevant to minor releases. So I started looking for alternatives.I found the Release notes generator and Wiki page creator GitHub actions. The first makes release notes for a closed milestone and saves them to a file in the virtual machine that runs the action. The second action then reads those notes and publishes them to the repo's wiki (so they're visible once the action completes). The idea is then that we'd copy/paste them into the release notes for the new release (like we do with
drush rn
) and then delete (or keep?) the wiki page.I've tested this on my repo and got it working, but a better test will be to merge this into this repo (where the issues/milestones are) and test it 'live'. There's no danger in doing so, as the action is only triggered when a milestone is closed, and the only thing it does is publish a wiki page. Everything is undo-able (milestones can be opened/closed and wiki pages can be deleted). Also, the PR (see below) only adds two files to this repo, so they're easily delete-able too if we decide not to go ahead after testing this.
The text was updated successfully, but these errors were encountered: