Bump actions/setup-node from 3 to 5 #1098
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 5. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v3...v5) --- updated-dependencies: - dependency-name: actions/setup-node dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| @@ -13,7 +13,7 @@ jobs: | |||
| - name: Setup pnpm | |||
| uses: pnpm/action-setup@v3 | |||
| - name: Set node version | |||
| uses: actions/setup-node@v3 | |||
| uses: actions/setup-node@v5 | |||
There was a problem hiding this comment.
The upgrade to actions/setup-node@v5 enables automatic package manager caching, but the workflow still has manual caching steps that will conflict with the new automatic caching.
View Details
📝 Patch Details
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 3858b42..2e16082 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -17,14 +17,7 @@ jobs:
with:
cache: 'pnpm'
node-version: '20'
- - name: Cache node_modules
- id: node-modules-cache
- uses: actions/cache@v4
- with:
- path: '**/node_modules'
- key: node-modules-cache-${{ hashFiles('**/pnpm-lock.yaml') }}
- name: Install dependencies
- if: steps.node-modules-cache.outputs.cache-hit != 'true'
run: pnpm install
- name: Run tests
run: pnpm test
Analysis
Caching Conflict in GitHub Actions Workflow
Issue Summary
The GitHub Actions workflow in .github/workflows/test.yml contains a caching configuration that creates redundancy and potential conflicts due to the upgrade to actions/setup-node@v5. This version introduced automatic package manager caching that overlaps with the existing manual caching implementation.
Root Cause Analysis
Automatic Caching in setup-node@v5
The v5.0.0 release of actions/setup-node introduced a breaking change: automatic caching when a valid packageManager field is present in package.json. This project's package.json contains:
{
"packageManager": "[email protected]"
}Current Workflow Configuration Issues
The workflow currently employs a dual caching approach:
- Automatic caching (line 18):
cache: 'pnpm'parameter insetup-node@v5 - Manual caching (lines 20-27): Explicit
actions/cache@v4step with conditional install logic
This creates several problems:
- Redundant operations: Both caching mechanisms target dependency management for the same package manager
- Cache key conflicts: Different caching strategies may use incompatible cache keys
- Workflow logic issues: The conditional install step (
if: steps.node-modules-cache.outputs.cache-hit != 'true') assumes manual cache control, but automatic caching may interfere with this logic - Resource waste: Unnecessary CI time spent on duplicate caching operations
Technical Details
Setup-node@v5 Caching Behavior
According to the action specification, setup-node@v5 includes:
package-manager-cache: Defaults totrue, enables automatic caching whenpackageManagerfield is detectedcache: Specifies package manager for built-in caching functionality- Uses
actions/cacheinternally with optimized cache keys
The automatic caching targets package manager stores (like pnpm store), while the manual caching targets node_modules directories. However, both affect the same dependency installation process.
Impact Assessment
Performance Impact
- Increased CI time: Redundant cache operations add overhead
- Cache storage usage: Multiple cache entries for the same dependencies
- Network overhead: Potential for unnecessary cache uploads/downloads
Reliability Impact
- Unpredictable behavior: Conditional logic may not work as expected with automatic caching
- Cache invalidation issues: Different caching strategies may have different invalidation triggers
Recommended Solution
Choose one of two approaches:
Option 1: Use Automatic Caching (Recommended)
Remove manual caching and rely on setup-node@v5's built-in functionality:
- name: Set node version
uses: actions/setup-node@v5
with:
cache: 'pnpm'
node-version: '20'
- name: Install dependencies
run: pnpm installOption 2: Disable Automatic Caching
Keep manual caching and disable the automatic behavior:
- name: Set node version
uses: actions/setup-node@v5
with:
package-manager-cache: false
node-version: '20'The automatic caching approach (Option 1) is recommended as it's simpler, maintained by GitHub, and optimized for the detected package manager.
Bumps actions/setup-node from 3 to 5.
Release notes
Sourced from actions/setup-node's releases.
... (truncated)
Commits
a0853c2Bump actions/checkout from 4 to 5 (#1345)b7234ccUpgrade action to use node24 (#1325)d7a1131Enhance caching in setup-node with automatic package manager detection (#1348)5e2628cBumps form-data (#1332)65becefBump undici from 5.28.5 to 5.29.0 (#1295)7e24a65Bump uuid from 9.0.1 to 11.1.0 (#1273)08f58d1Bump@octokit/request-errorand@actions/github(#1227)49933eaBump@action/cachefrom 4.0.2 to 4.0.3 (#1262)e3ce749feat: support private mirrors (#1240)40337cbAdd support for indented eslint output (#1245)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)