ci(release): post release notes to the announcements discussion board - #3707
Conversation
github-actions
Bot
added
area-community
Link each GitHub release to a discussion in the Announcements category so the announcement post happens automatically at release time. Guarded off on forks, where the category may not exist and an unknown category fails release creation.
19c7aea to
1494780
Compare
|
Issue: The same three-line block (permission + env var + flag) is now copy-pasted identically across Suggestion: This is a pre-existing structural pattern (the release workflows are already largely duplicated), so not blocking here — but if these keep growing in lockstep, a reusable/composite workflow for the shared "tag + create release + announce" step would remove the drift risk. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Assessment: Comment Clean, small, and unusually well-documented change that closes a real gap (announcements silently stopping after the manual step was dropped). The permission scoping, the Review Categories
Nice attention to detail on the comments explaining why at each step — it made this easy to review. |
Creating the release with --discussion-category made the category's existence a release-blocking invariant: an unknown category fails gh release create after the tag is already pushed. Create the release without the flag and link the discussion afterwards via a category PATCH, downgrading failures to a warning like the changelog dispatch.
3 participants
Description
Release announcements on the Discussions board stopped after
python/v1.45.0andtypescript/v1.7.0: those posts were created manually via the "create a discussion for this release" checkbox on the release page, and the automated release workflows never picked that step up. This links each release to a discussion in the existing Announcements category at creation time, so the announcement happens as part of the release instead of depending on someone remembering.The linked discussion has the same shape as the historical posts: title is the tag, body is the release notes. The announcement is posted in its own non-fatal step after the release exists, mirroring the changelog dispatch: a missing or renamed category degrades to a warning instead of failing a release whose tag is already pushed. On forks the step is skipped, since Discussions or the category may not exist there.
Related Issues
None.
Documentation PR
No documentation changes needed.
Type of Change
Other (please describe): release workflow change
Testing
How have you tested the change? Verify that the changes do not break functionality or introduce new warnings.
actionlintpasses on all three release workflows.Exercised the linking mechanism against throwaway releases on a fork: a category PATCH on a published release creates and links the discussion (title is the release title, body is the notes), re-running the PATCH is a no-op returning the same discussion, and an unknown category returns HTTP 404 without touching the release, which is the path the non-fatal warning covers. Probe releases and discussions were deleted afterwards.
Simulated the step's failure path under
set -euo pipefailwith a stubbed failinggh: the warning is emitted and the step exits 0.The full workflow path cannot be exercised before merge: dry runs skip
create-gh-release, and fork runs skip the announcement step by design.I ran
hatch run prepare(not applicable: no Python SDK changes)Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.