Add prepare-release-notes and create-draft-release scripts - #2556
Conversation
Assemble the release notes for the plugins currently being released — those with an open, dated milestone whose title does not contain "n.e.x.t" — by reading each plugin's stable-tag changelog entry from its readme.txt (as populated by npm run readme). Progress and warnings go to STDERR so STDOUT (the Markdown notes) can be piped to a file or the clipboard. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Create a draft GitHub release for the release date, using the combined per-plugin changelogs from `npm run prepare-release-notes` as the body. The tag and title are $RELEASE_DATE and the target is the release/$RELEASE_DATE branch. Fails early if the target branch is missing on origin or a release for the tag already exists, and authenticates the milestone lookup with the gh token to avoid rate limiting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
westonruter
added
the
[Type] Enhancement
westonruter
added
the
skip changelog
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## trunk #2556 +/- ##
==========================================
- Coverage 70.38% 70.35% -0.03%
==========================================
Files 91 91
Lines 7850 7867 +17
==========================================
+ Hits 5525 5535 +10
- Misses 2325 2332 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
westonruter
added
the
no milestone
| # Avoid clobbering an existing release/tag; drafts are cheap to delete and recreate. | ||
| if gh release view "$tag" &> /dev/null; then | ||
| echo "Error: A release for tag \"$tag\" already exists. Delete it first with:" >&2 | ||
| echo " gh release delete \"$tag\"" >&2 | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
How do we know we are not suggesting to delete an already published release? Maybe check if it's a draft and then suggest to delete it?
Also, maybe add a macro if there could be more releases per day? like YYYY-MM-DD.N?
There was a problem hiding this comment.
We only create tags for releases, right? Er, the other way around. We only create a tag and a release at the same time following this scheme. So if it already exists, then that means the release was already made and the user should change the release target. So perhaps this message should advise to only delete if a mistake had been made. Otherwise, a corrected version should be supplied.
There was a problem hiding this comment.
So if it already exists, then that means the release was already made and the user should change the release target.
Yes, and this message shouldn't suggest deleting it, right? given it's not even possible to delete if it's an immutable release.
If this is just a draft (and the tag may also need to point to the latest commit), then it's okay to suggest deleting the existing release and tag. But if it's not a draft and has already been published, it should simply say: A release for this tag already exists and can't be overridden.
Only suggest `gh release delete` when the existing release is still a draft. A published release is immutable, so advise supplying a different RELEASE_DATE instead. Co-authored-by: thelovekesh <thelovekesh@git.wordpress.org> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3 participants
This introduces two new scripts that help automate the release process:
npm run gather-release-notesnpm run create-draft-releaseThe former is called automatically be the later. I've updated the handbook page to explain how they are used. I used them in the most recent release.
Use of AI Tools
Changes were authored by Claude Opus 4.8 based on my prompts.