Release workflow #544
Release workflow #544
Conversation
Signed-off-by: Paul Sachs <psachs@buf.build>
Signed-off-by: Paul Sachs <psachs@buf.build>
|
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 <psachs@buf.build>
Signed-off-by: Paul Sachs <psachs@buf.build>
| echo "✓ Version '${{ inputs.version }}' is valid semver" | ||
|
|
||
| - name: Install dependencies | ||
| run: npm install |
There was a problem hiding this comment.
| run: npm install | |
| run: npm ci |
| with: | ||
| node-version-file: ".nvmrc" | ||
| cache: "npm" | ||
| registry-url: "https://registry.npmjs.org" |
There was a problem hiding this comment.
Why are we setting registry-url here, but not elsewhere?
There was a problem hiding this comment.
I was also caught by this. It was not something I thought was necessary but then the example docs in setup-node actually make this explicit (see example here). It might not at all be necessary but since github actions are annoying to test, I went with their example.
Looking closer at the example, they might have only done it because they were also publishing to github packages as well, so probably not necessary at all.
| registry-url: "https://registry.npmjs.org" | ||
|
|
||
| - name: Install dependencies | ||
| run: npm install |
There was a problem hiding this comment.
| run: npm install | |
| run: npm ci |
| - 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.
| 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 <psachs@buf.build>
Signed-off-by: Paul Sachs <psachs@buf.build>
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 but all we need is an NPM token configured as a secret and it should work.
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.