Bump actions/setup-node from 3 to 6 #19206
Conversation
dependabot
bot
added
dependencies
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
dannyroosevelt
moved this to Ready for PR Review
in Component (Source and Action) Backlog
WalkthroughAcross multiple GitHub workflow files the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
.github/workflows/push-registry-app-files-supabase.yaml (1)
25-44: I'll search for the official documentation on actions/setup-node@v6 to verify the claims about automatic pnpm caching.Based on my verification through official GitHub Actions documentation and pnpm project issues, I found key information about the cache configuration.
A GitHub issue in the pnpm/action-setup repository confirms that having both setup-node cache: 'pnpm' and manual actions/cache create duplicate caching to the same directory, describing it as a duplication. The official pnpm documentation for GitHub Actions shows the recommended pattern uses pnpm/action-setup followed by actions/setup-node@v4 with cache: 'pnpm' and then pnpm install.
However, the original review comment contains a misleading explanation. According to setup-node documentation, for pnpm, caching is disabled by default and must be configured manually using the cache input—this is not automatic. The cache: 'pnpm' parameter is explicit configuration, not automatic behavior.
Redundant pnpm cache configuration in setup-node v6.
Lines 25-38 (manual pnpm cache setup with actions/cache@v4) and line 40 (setup-node with cache: 'pnpm') are redundant. Both write to the same pnpm store directory. Remove the manual cache steps (lines 25-38) and keep only the
cache: 'pnpm'configuration in the setup-node step.Note: Pnpm caching is not automatic by default; it requires explicit configuration via the cache input.
.github/workflows/pull-request-checks.yaml (1)
62-83: Now I need to verify the actual workflow file to confirm the code and line numbers match:Based on my verification through web searches and documentation review, the original review comment's analysis is accurate. The official setup-node v6 documentation shows the recommended sequence: pnpm/action-setup followed by setup-node with cache: 'pnpm', then pnpm install. When setup-node configures cache for pnpm, it should come before the install step to be effective.
In the current workflow, the
pnpm install -rstep executes beforesetup-node@v6, meaning the setup-node cache cannot assist with the initial install. The setup-node action uses actions/cache under the hood for caching and supports pnpm, making the manual cache setup redundant when combined with thecache: 'pnpm'parameter.Restructure the workflow to fix the step ordering and eliminate redundancy.
The manual pnpm cache setup (lines 62-75) should be removed entirely, and
setup-node@v6should be moved before thepnpm install -rstep. This follows the documented best practice: pnpm/action-setup → setup-node with cache → pnpm install. This way, the cache is prepared before dependencies are installed..github/workflows/publish-marketplace-content.yaml (1)
15-36: Redundant and misordered pnpm cache setup — fix required.The workflow contains a caching redundancy with incorrect ordering. The manual pnpm cache (using actions/cache@v4) executes before
pnpm install, butsetup-node@v6withcache: 'pnpm'comes after the install. According to GitHub Actions best practices, setup-node's cache mechanism must be configured before the install step to take effect; the current ordering means the initial install does not benefit from setup-node's automatic caching.Remove the manual cache setup (lines 17–27) and move
setup-node@v6before thepnpm installstep, or keep the manual cache and remove thecache: 'pnpm'parameter from setup-node..github/workflows/publish-components.yaml (2)
123-142: Remove redundant caching configuration—either use manualactions/cache@v4ORsetup-node'scache: 'pnpm', not both.The workflow correctly installs pnpm before
setup-node@v6, so the automaticcache: 'pnpm'parameter will work. However, the manual cache setup (lines 27-37) and thecache: 'pnpm'parameter (line 43) both target the same pnpm store directory, creating redundancy. Choose one caching strategy: either remove the manual cache steps and rely onsetup-node's built-in caching, or remove thecache: 'pnpm'parameter.
15-36: Redundant pnpm cache in both publish jobs.Manual pnpm cache (lines 22–28) conflicts with
setup-node@v6's automaticcache: 'pnpm'parameter (line 32). In the publish-components job, the automatic cache runs afterpnpm install(line 30), providing no benefit. In publish-typescript-components (lines 130–144), the same redundancy exists despite better step ordering.Remove the manual
actions/cache@v4steps and ensuresetup-node@v6runs beforepnpm install, or remove thecache: 'pnpm'parameter and keep the manual cache. Choose one caching strategy consistently across both jobs..github/workflows/components-pr.yaml (1)
141-160: Remove redundant pnpm cache configuration in publish-typescript-components-dry-run job.Lines 145-154 set up manual pnpm cache while line 160 includes
cache: 'pnpm'in setup-node@v6—these are redundant. Other workflows (e.g., scheduled-package-validation.yaml) use setup-node's automatic caching exclusively. Either remove the manual cache setup (lines 145-154) and keepcache: 'pnpm', or removecache: 'pnpm'and retain manual cache for consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
.github/workflows/components-pr.yaml(2 hunks).github/workflows/pipedream-sdk-test.yaml(1 hunks).github/workflows/publish-components.yaml(2 hunks).github/workflows/publish-marketplace-content.yaml(1 hunks).github/workflows/publish-packages.yaml(1 hunks).github/workflows/publish-platform-package.yaml(1 hunks).github/workflows/pull-request-checks.yaml(1 hunks).github/workflows/push-registry-app-files-supabase.yaml(1 hunks).github/workflows/scheduled-package-validation.yaml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
🔇 Additional comments (4)
.github/workflows/scheduled-package-validation.yaml (1)
18-30: Correct pnpm caching setup for setup-node v6.This workflow correctly implements the v6 upgrade without redundant manual pnpm cache steps. The setup-node automatic caching via
cache: 'pnpm'is properly positioned before the pnpm install, allowing the install step to benefit from cached dependencies..github/workflows/components-pr.yaml (1)
52-71: ****The stated execution order is incorrect. In the workflow,
setup-node@v6(lines 64–69) executes beforepnpm install -r(lines 70–71), not after. The execution sequence is correct.However, there is a legitimate caching redundancy: both the manual
actions/cache@v4(lines 57–63) andsetup-node@v6withcache: 'pnpm'(lines 64–69) manage pnpm caching. You can simplify by removing the manual cache configuration and relying solely on setup-node's automatic caching, or vice versa. This same pattern exists in thepublish-typescript-components-dry-runjob (lines ~141–162).Likely an incorrect or invalid review comment.
.github/workflows/publish-packages.yaml (1)
24-44: The asymmetric caching strategy is intentional and follows best practices; no major issue exists.The conditional manual cache and unconditional
setup-nodecache are both by design:
- The inline comment documents that manual cache is deliberately disabled for
masterbranch (dry runs only)setup-node@v6withcache: 'pnpm'is the GitHub Actions recommended approach for automatic dependency caching and runs on all branches as intended- Both can coexist without conflict; setup-node handles caching automatically while the manual layer provides explicit control for non-master runs
The manual cache layer may be somewhat redundant given
setup-node's built-in caching, but this is a minor inefficiency, not a critical flaw. The workflow is documented and functioning correctly.Likely an incorrect or invalid review comment.
.github/workflows/publish-platform-package.yaml (1)
19-23: ✓ actions/setup-node v6 correctly configured with pnpm caching fully verified.The web search confirms that actions/setup-node v6 supports the
cache: 'pnpm'parameter. The workflow correctly satisfies the requirement of installing pnpm separately before using the cache—pnpm/action-setup@v4.0.0at line 16 runs beforesetup-node@v6at lines 19-23, ensuring pnpm is available when caching is enabled.
| - name: Set up Node.js | ||
| uses: actions/setup-node@v3 | ||
| uses: actions/setup-node@v6 | ||
| with: | ||
| node-version: '22' | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
Inconsistent setup-node cache configuration compared to other workflows.
Unlike other workflows in this PR, setup-node@v6 here does not include cache: 'pnpm'. The workflow still relies solely on manual pnpm cache (lines 21-34). All other updated workflows add cache: 'pnpm' to enable setup-node v6's automatic pnpm caching.
Verify whether this difference is intentional (e.g., due to node version 22 vs 18) or should be aligned with other workflows for consistency.
Confirm whether cache: 'pnpm' should be added here to match the pattern in other workflows, or if manual caching is intentionally preferred for SDK tests.
🏁 Script executed:
#!/bin/bash
# Find all workflow files and display their setup-node configurations
echo "=== All workflow files in .github/workflows ==="
fd -e yaml -e yml . .github/workflows/ 2>/dev/null | sort
echo -e "\n=== Checking setup-node configurations ==="
for file in .github/workflows/*.{yaml,yml} .github/workflows/**/*.{yaml,yml} 2>/dev/null; do
if [ -f "$file" ]; then
echo -e "\n--- $file ---"
rg -A5 "actions/setup-node" "$file" || echo " (no setup-node found)"
fi
doneLength of output: 733
🏁 Script executed:
#!/bin/bash
# Extract setup-node configurations from all workflow files
echo "=== setup-node configurations across workflows ==="
for file in .github/workflows/*.yaml .github/workflows/*.yml; do
if [ -f "$file" ]; then
echo -e "\n--- $file ---"
rg -B2 -A8 "setup-node" "$file"
fi
done
echo -e "\n=== Checking manual pnpm cache in pipedream-sdk-test.yaml (lines 21-34) ==="
sed -n '21,34p' .github/workflows/pipedream-sdk-test.yamlLength of output: 4822
Align setup-node cache configuration with other workflows.
Verified: pipedream-sdk-test.yaml is the only workflow using setup-node@v6 without the cache: 'pnpm' parameter. All 8 other workflows (components-pr.yaml, publish-components.yaml, publish-packages.yaml, pull-request-checks.yaml, etc.) include this parameter. While the manual pnpm cache (lines 21-34) works correctly, adding cache: 'pnpm' to lines 36-40 would align this workflow with the established pattern and leverage setup-node v6's native caching feature.
🤖 Prompt for AI Agents
In .github/workflows/pipedream-sdk-test.yaml around lines 36 to 40, the
actions/setup-node@v6 step is missing the cache: 'pnpm' parameter used across
other workflows; add cache: 'pnpm' under the with: block for setup-node so it
uses native pnpm caching (removing or keeping the manual pnpm cache step is
optional but aligning to other workflows requires adding cache: 'pnpm' here).
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 6. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v3...v6) --- updated-dependencies: - dependency-name: actions/setup-node dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
force-pushed
the
dependabot/github_actions/actions/setup-node-6
branch
from
35edd73 to
4c66f80
Compare
luancazarine
moved this from Ready for PR Review
to In Review
in Component (Source and Action) Backlog
luancazarine
deleted the
dependabot/github_actions/actions/setup-node-6
branch
github-project-automation
bot
moved this from In Review
to Done
in Component (Source and Action) Backlog
Bumps actions/setup-node from 3 to 6.
Release notes
Sourced from actions/setup-node's releases.
... (truncated)
Commits
2028fbcLimit automatic caching to npm, update workflows and documentation (#1374)1342781Bump actions/publish-action from 0.3.0 to 0.4.0 (#1362)89d709dBump prettier from 2.8.8 to 3.6.2 (#1334)cd2651cBump ts-jest from 29.1.2 to 29.4.1 (#1336)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)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)Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.