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]>
| - name: Validate semver version | ||
| run: | | ||
| if ! echo "${{ inputs.version }}" | grep -E '^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+(\.[a-zA-Z0-9]+)*)?(\+[a-zA-Z0-9]+(\.[a-zA-Z0-9]+)*)?$'; then | ||
| echo "Error: '${{ inputs.version }}' is not a valid semver version" | ||
| echo "Expected format: MAJOR.MINOR.PATCH (e.g., 1.2.3) or with pre-release/build metadata (e.g., 1.2.3-alpha.1+build.1)" | ||
| exit 1 | ||
| fi | ||
| echo "✓ Version '${{ inputs.version }}' is valid semver" |
There was a problem hiding this comment.
I wonder if we can roll this check into the setversion script. It already uses a similar regex, and IMO it would be beneficial to have only a single piece of code checking the version number.
If the step for setversion moves up, this should work out, right?
There was a problem hiding this comment.
Actually, looking at the set-workspace-version.js file, this is not necessary. We are already checking the incoming version and in fact don't allow things like "rc" releases so I'll just remove this entirely and defer to setversion
There was a problem hiding this comment.
In protovalidate-es, set-workspace-version.js was crudely modified to accept RC versions. Would be nice to improve the regex a bit with what you have here, and also improve the error handling so that it returns a more helpful message.
There was a problem hiding this comment.
Sure. I've updated set-workspace-version.js to have an improved regexp and also add an error specifically if the version is invalid. Should be sufficient for now.
Instead of what I have here, I used regex from here instead.
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
||
| - name: Comment on fixed issues |
There was a problem hiding this comment.
Comments on fixed issues with a link to the release are great. But I think we'll have an easier time landing the release automation in all repositories if we decouple this step from the release workflow. For example, by putting into into a separate workflow we can adopt separately.
- 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]>
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.