Update workflows and action to NodeJS 20 #166
Conversation
.github/workflows/check-dist.yml
Outdated
| - name: Set Node.js 16.x | ||
| uses: actions/setup-node@v3.7.0 | ||
| - name: Set Node.js 20.x | ||
| uses: actions/setup-node@v4.0.1 |
.github/workflows/ci.yml
Outdated
| uses: actions/setup-node@v3.7.0 | ||
| - uses: actions/checkout@v4 | ||
| - name: Set Node.js 20.x | ||
| uses: actions/setup-node@v4.0.1 |
There was a problem hiding this comment.
Same question applies from check-dist review.
There was a problem hiding this comment.
Latest version seems to be 4.0.1
https://github.com/actions/setup-node/releases/tag/v4.0.1
There was a problem hiding this comment.
not what i meant, meant that you can use v4 to have it auto-choose the latest version instead of having to relay on a specific version tag - essentially a wildcard of some sort.
There was a problem hiding this comment.
Could as well be v4, but as the current workflow has the version pinned, I decided to keep the convention. Probably should have to look into the file history a bit, for decisions why it was pinned.
There was a problem hiding this comment.
Checked the file history and it seems to have been created with the pinned version already in place, although for me - i don't see the reasoning why this should stay pinned unless it was for an urgent reason which i couldn't find.
|
@JLLeitschuh How do you feel about bumping the required Node version without a major version bump of the action? (In general this is considered a breaking change). |
I find it very unlikely that others are binding to this action via the API directly. So in that case, is that truly an "API" breaking change? I don't think it is. If we were changing the API of the |
|
Also, @bigdaz, I'm not a maintainer on any https://github.com/gradle projects anymore, so ultimately, it's your and @eskatos's call I'm not against being made a maintainer on this project once again, but, as it currently stands, this project is completely outside my control |
It's a breaking change in that the action will no longer run on older runners that don't have a recent version of node installed. This would only be a problem for self-hosted runners (and I guess old versions of GitHub Enterprise). |
🤔 This is super helpful. Honestly, I could go either way. I think that since, for the predominant use case, on GitHub.com this will not be an API breaking change I'm not too concerned. Does anyone else want to weigh in on how this question has been handled by other popular actions? I'm also happy to reach out to GitHub folks internally and see if they have advice. |
My observation is that all of the action implementations from https://github.com/actions have had a major version bump with the update to Node 20. I guess we should do the same, even though the risk is low. |
|
I can support that. It's already the suggestion of the Open Source Security Foundation to bind your actions versions to commit hashes, instead of open versions to prevent supply chain attacks. And I believe that's what Dependabot has started doing as well, so our end-users will likely get a PR to rev the version regardless of how we do this. |
I haven't seen this. My understanding is that Dependabot will keep the version scheme you are currently using. So if you bind to I'm not sure what Dependabot does with commit-hash versions: perhaps handling these correctly is something recently added to Dependabot. |
|
This was subsumed by #170. Thanks for the contribution! |
Build with recent @actions/core and Node 20
Fixes #160