- 
                Notifications
    You must be signed in to change notification settings 
- Fork 23
Release workflow #544
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
base: main
Are you sure you want to change the base?
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]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated script to use api directly, much easier to understand with less side effects 🚀
| branches: | ||
| - main | ||
| - "release/**" | ||
| - "hotfix/**" | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot: Why do we need release and hotfix? What's the distinction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain how this would be used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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]>
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.