CI setup for nodejs.org release notesΒ #35530
Copy link
Copy link
Closed as not planned
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
Description
Is your feature request related to a problem? Please describe.
Please describe the problem you are trying to solve.
Currently the blog post for new releases is a manual process as mentioned in https://github.com/nodejs/node/blob/b15ed6515323ec6cae2bde78feabf805c2fbb6b1/doc/guides/releases.md#17-create-a-blog-post
Describe the solution you'd like
Please describe the desired behavior.
When a new GitHub Release is created:
- Trigger the job based off of https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#release the
publishedorcreatedevent - Take content from the release. EX: https://github.com/nodejs/node/releases/tag/v12.19.0
- Create a PR to nodejs.org repo like Blog: v12.19.0 release postΒ nodejs.org#3436
Alternate flow would include the release updated event to either update the existing PR or create a new PR if information is added.
Describe alternatives you've considered
Please describe alternative solutions or features you have considered.
Keep it manual, as this is a small activity
/cc @nodejs/releasers
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
Activity
MylesBorins commentedon Oct 6, 2020
@codebytere and I were just talking about what we could do to automate the creation of the Release. One challenge we might find would be that the tag is generally pushed before the release is promoted and the assets / signatures are ready.
nschonni commentedon Oct 6, 2020
So I think maybe limiting to the
publishedrelease type would allow controlling thatcodebytere commentedon Oct 7, 2020
One potential avenue here is firing off the blog post job via
repository_dispatchhook and the new version when the assets are promoted as part of the release shell script - i'd be happy to throw together a quick prototype for that over on the website repo with a description of what the POST request would need to look like!nschonni commentedon Oct 7, 2020
Whatever works best for you, since it's currently your manual process :)
You might want to take a look at nodejs/docker-node#1337 on how docker-node will be sending the PR cross repo. The same bot token could probably be used here.
targos commentedon Oct 7, 2020
The creation of the GitHub release sounds like a good event since it's the last step of the releaser's job. Everything should be ready at that point
github-actions commentedon Jun 27, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 28, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.