Release workflow #544
Release workflow #544
Conversation
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
|
After this is merged, I can run it through some dry runs of the first prepare stage which can be considered a noop if the branch is closed with accepting. |
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
- Moved to npm ci - Split issue updates into a distinct action - Removed unnecessary registry option on publish setup Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
|
Actually, looking a little more into this, we probably want to integrate trusted publishing instead of using a token. Will need to investigate what that means here but i think it's a better way than using a long lived token. |
Signed-off-by: Paul Sachs <[email protected]>
|
Alright, updated. After a little bit of click ops on each package, following these instructions, we no longer need a token and we get providence and everything. |
Signed-off-by: Paul Sachs <[email protected]>
Also removed update fixed issues action which wouldn't trigger since the triggering event is a github action and github actions prevents cascading actions. Signed-off-by: Paul Sachs <[email protected]>
|
Confirmed working in this repo: https://github.com/paul-sachs/npm-publish-test. Some minor adjustments have been made to fix cleanup and I've removed the fixed issues action since it wasn't triggering as a cascading action (github prevents cascading actions). |
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
timostamm
left a comment
timostamm
left a comment
There was a problem hiding this comment.
Nice. Let's get this merged here, and apply to other relevant repositories after running it for a while.
scripts/release.js: Can you update the comment that recommends the procedure for releases?
.github/RELEASING.md: Can you update this document for the new release process?
| git commit -s -m "Release ${{ inputs.version }}" | ||
| git push --set-upstream origin "release/prep-release-${{ inputs.version }}" | ||
| - name: Get release notes |
There was a problem hiding this comment.
Is this the reason to draft a release? Then I suggest that we create a draft, get the generated release notes, and delete the draft.
Can you add a comment that we should switch to an API call to generate release notes without creating a release? https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#generate-release-notes-content-for-a-release
There was a problem hiding this comment.
Updated script to use api directly, much easier to understand with less side effects 🚀
There was a problem hiding this comment.
Why not kick the action off by manually creating a draft release and editing the release notes up front? The prepare-release action could trigger on that event, pick up the release tag, target branch, and release notes, create the release branch and PR, and delete the draft release.
It wouldn't be very different from what you have, but it would make use of the "new release" UI rather than the more esoteric UI to trigger a workflow.
One downside I see is that you could accidentally create a non-draft release in the UI... but this could maybe be handled by permissions or even detected and cleaned up by the prepare-release workflow?
There was a problem hiding this comment.
The original idea was to leverage a review process, which is more central to this current version (everything pivots off the PR). Creating a release doesn't really have associated workflows so we'd need to do cleanup. But both would obviously work.
There was a problem hiding this comment.
Yeah, totally get why you're using a PR for review, and I wasn't suggesting changing that. I was just suggesting using the draft release creation to kick off the flow which would seem marginally more GitHub-idiomatic to me, even though you still wouldn't be publishing the draft release actually created since it would just be tagged from main (or from a branch for a backport).
There was a problem hiding this comment.
Ah i think i now understand what you meant. So instead of triggering via workflow run, we'd trigger on a draft release creation. Yeah, has a little more cleanup but i can see why that might be a little more natural.
There was a problem hiding this comment.
@timostamm do you have thoughts on this? Using a draft release as the trigger feels a little more intuitive vs an arbitrary workflow.
| branches: | ||
| - main | ||
| - "release/**" | ||
| - "hotfix/**" |
There was a problem hiding this comment.
I forgot: Why do we need release and hotfix? What's the distinction?
There was a problem hiding this comment.
This was more of a hypothetical, but the idea is that if we need to release for v1 but we are currently on v2, a hotfix indicates that the release will be based off of the a specific tag. All that said, I actually don't think we need a distinction now, since all we're using this for is to pull out the version to be based on. I think we can simplify to just main and release/**
| base_branch: | ||
| description: "Base branch for release (e.g. release/v1.x, hotfix/v1.2.x)" |
There was a problem hiding this comment.
Can you explain how this would be used?
There was a problem hiding this comment.
I've added some additional text to try to explain why we'd want a difference base_branch
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
- Updated releasing process notes - Used API to get release notes to avoid draft release - Use shared js util to get workspace version Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
Signed-off-by: Paul Sachs <[email protected]>
This is a modified version of a local script i've been using for a few releases. Hasn't been tested as an action yet so we'll need a new release to validate.
New workflows for release management:
Prepare Release Workflow:
.github/workflows/prepare-release.ymlto automate the creation of draft releases, release branches, and pull requests for new versions. Includes support for potential release/hotfix base branches in the case of a backport fix. To create a backport, we'll just need to create a branch for the target base version (release/v1.x) and set the base branch for the action.Publish Release Workflow:
.github/workflows/publish-release.ymlto handle the publication of merged release pull requests, including publishing to npm, updating GitHub release notesUpdate Fixed Issues Workflow:
.github/workflows/updated-fixed-issues.ymlto comment on fixed issues.