ci: upgrade node version to 24#240
Conversation
| runs-on: self-hosted | ||
| container: | ||
| image: node:20 | ||
| image: node:24 |
There was a problem hiding this comment.
Non-LTS Node.js version: Node.js 24 is a "Current" release, not an LTS version. For CI workflows, it's recommended to use an LTS release (e.g., Node 22, which is the active LTS) for better stability, longer support, and fewer breaking changes. Non-LTS versions have shorter support windows and may introduce unexpected issues.
Consider using node:22 instead, or if Node 24 features are specifically needed, pin to a specific minor/patch version (e.g., node:24.x.y) to avoid unexpected updates.
| runs-on: self-hosted | ||
| container: | ||
| image: node:20 | ||
| image: node:24 |
There was a problem hiding this comment.
Container image tag not fully pinned: Using node:24 (major version only) means the actual image can change when new minor/patch releases are published (e.g., 24.1 → 24.2), potentially causing non-reproducible builds or unexpected breakages. Consider pinning to at least a minor version (e.g., node:24.1) or a specific SHA digest for maximum reproducibility.
This applies to both the build and deploy jobs.
| runs-on: self-hosted | ||
| container: | ||
| image: node:20 | ||
| image: node:24 |
There was a problem hiding this comment.
Potential compatibility risk: This jumps directly from Node.js 20 to Node.js 24, skipping Node.js 22 (LTS). Since this is a release-critical job (npm-publish), consider first validating that all npm operations (npm publish, npm view, jq interactions) work correctly with Node.js 24's bundled npm version. Also consider using a more specific image tag (e.g., node:24.x.y) for reproducible builds in release workflows, rather than a floating major-version tag.
Description
Type of Change
How Has This Been Tested?
make testpasses locallyManually testing local build and review actions using new version of node.
Checklist
go fmt,go vet)Related Issues