Skip to content

Conversation

@justin808
Copy link
Member

@justin808 justin808 commented Nov 5, 2025

Summary

The previous attempt to disable yarn caching for Node 22 using cache: '' caused CI failures because GitHub Actions setup-node doesn't accept empty strings for the cache parameter and still attempts to initialize caching.

This PR reverts all workflows to use Node 20 until the V8 bug is resolved (nodejs/node#56010).

Key Changes

  • Revert lint-js-and-ruby.yml from Node 22 to Node 20 with normal caching
  • Revert main.yml matrix to use Node 20 for both latest and minimum dependency levels
  • Simplify package-js-tests.yml to only test Node 20
  • Remove conditional cache logic that was causing failures
  • Remove conditional frozen-lockfile flag that depended on Node 22

CI Failures Fixed

This PR addresses the following CI failures:

Test Plan

  • RuboCop passes locally
  • Git hooks pass (prettier, trailing newlines check)
  • CI workflows pass with Node 20 configuration

🤖 Generated with Claude Code


This change is Reviewable

The previous attempt to disable yarn caching for Node 22 using cache: '' caused CI failures because GitHub Actions setup-node doesn't accept empty strings for the cache parameter and still attempts to initialize caching, resulting in "Could not get yarn cache folder path" errors.

This commit reverts all workflows to use Node 20 until the V8 bug is resolved. This is a temporary workaround that ensures CI stability.

Changes:
- Revert lint-js-and-ruby.yml from Node 22 to Node 20 with normal caching
- Revert main.yml matrix to use Node 20 for both latest and minimum dependency levels
- Simplify package-js-tests.yml to only test Node 20
- Remove conditional cache logic that was causing failures
- Remove conditional frozen-lockfile flag that depended on Node 22

Related: nodejs/node#56010

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 5, 2025

Warning

Rate limit exceeded

@justin808 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 7 minutes and 23 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between ae5425b and 4350858.

📒 Files selected for processing (3)
  • .github/workflows/lint-js-and-ruby.yml (1 hunks)
  • .github/workflows/main.yml (3 hunks)
  • .github/workflows/package-js-tests.yml (3 hunks)
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch justin808/next

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@claude
Copy link

claude bot commented Nov 5, 2025

Code Review

Summary

This PR addresses CI failures by reverting all GitHub Actions workflows from Node.js 22 back to Node.js 20, working around a V8 cache crash issue. The changes are clean, focused, and pragmatic.


Code Quality and Best Practices

Strengths:

  • Clean reversion: All Node 22-specific conditional logic has been properly removed, simplifying the workflow files
  • Consistent approach: All three workflow files follow the same pattern, maintaining consistency
  • Good documentation: PR description clearly explains the rationale and links to relevant CI failures
  • Appropriate scope: Changes are limited to exactly what is needed to fix the issue

Observations:

  • The removal of conditional cache logic back to simple cache: yarn is correct and cleaner
  • The removal of conditional frozen-lockfile flags is also appropriate
  • Matrix strategy simplification in package-js-tests.yml (from include with multiple versions to simple array) is cleaner

Potential Issues

Minor concerns:

  1. Inconsistency in main.yml: There is one remaining reference to Node 22 at line 131 in the dummy-app-integration-tests job. This appears to be intentional based on the diff showing it was not changed, but it is worth verifying this is correct. This job runs after webpack bundles are built with Node 20, so it may be using a different Node version for the integration tests themselves.

  2. Missing V8 bug reference: The PR body mentions tracking sqlite: deps include sqlite3ext.h nodejs/node#56010, but this appears to be a different PR about SQLite headers. Consider verifying the correct issue URL for the V8 cache bug.


Security Considerations

No security concerns identified.

  • Changes are limited to CI configuration
  • No changes to dependency versions or code logic
  • Yarn cache is properly configured

Performance Considerations

Positive impact:

  • Restoring yarn caching will significantly improve CI build times compared to the previous attempt with empty cache
  • Node 20 is stable and well-tested, reducing potential for unexpected performance issues

Note:

  • Once the V8 bug is resolved in Node 22, upgrading will provide access to newer V8 optimizations

Test Coverage

Observations:

  • PR checklist shows RuboCop and git hooks passing
  • CI workflows themselves will validate the fix once they run
  • The changes are to CI configuration only, so no additional test coverage needed

Recommendation:

  • Monitor the first few CI runs to ensure Node 20 works correctly across all matrix combinations

Additional Recommendations

  1. Verify Node 22 reference: Check if line 131 in main.yml should also use Node 20, or if there is a specific reason for keeping Node 22 there
  2. Update V8 bug tracking: Confirm the correct GitHub issue URL for the V8 cache crash
  3. Create follow-up issue: Consider creating an internal issue to track re-enabling Node 22 once the upstream bug is fixed
  4. Document in CHANGELOG: Based on CLAUDE.md guidelines, this fix should NOT be added to CHANGELOG.md as it is an infrastructure/CI change, not a user-visible feature or bug fix

Overall Assessment

Recommendation: APPROVE

This is a solid, pragmatic fix that:

  • Resolves immediate CI failures
  • Simplifies workflow configuration by removing conditional logic
  • Maintains consistency across all workflow files
  • Has clear documentation of the rationale

The only item requiring clarification is the Node 22 reference in main.yml line 131, which may be intentional but should be verified.

Great work on quickly addressing the CI failures with a clean solution!


Reviewed with attention to CLAUDE.md guidelines and React on Rails conventions

@claude
Copy link

claude bot commented Nov 5, 2025

PR Review: Fix Node.js 22 V8 cache crash by reverting to Node 20

Overall Assessment

This PR takes the pragmatic approach of reverting to Node 20 across all workflows to avoid CI failures caused by the GitHub Actions setup-node issue with Node 22 caching. The changes are clean and well-documented.

Code Quality: ✅ Good

Strengths:

  • Clean revert of previous workaround attempts
  • Consistent changes across all affected workflow files
  • Good documentation in the PR summary explaining the issue
  • Links to relevant CI failures and upstream bug report

Observations:

  • The changes correctly simplify the workflows by removing conditional logic
  • Proper restoration of yarn caching for Node 20
  • Removal of conditional --frozen-lockfile flag

Issues Identified

1. Incomplete Coverage - Pro Workflows Still Use Node 22 ⚠️ CRITICAL

The following workflow files still reference Node 22 and have the same problematic empty cache configuration:

  • .github/workflows/pro-integration-tests.yml (lines 54, 144, 335)
  • .github/workflows/pro-lint.yml (line 53)
  • .github/workflows/pro-package-tests.yml (lines 54, 149)

These files contain:

node-version: 22
cache: ''  # This will cause the same CI failures

Impact: Pro workflow CI jobs will fail with the same error this PR is trying to fix.

Recommendation: Update all Pro workflows to use Node 20 with proper caching, matching the changes in the main workflows.

2. Documentation Inconsistency ⚠️ MEDIUM

docs/CI_OPTIMIZATION.md still documents the CI strategy as:

| Node versions | 20, 22          | 22 only       |

And contains example code using Node 22:

node-version: ${{ github.ref == 'refs/heads/master' && fromJSON('["20", "22"]') || fromJSON('["22"]') }}

Recommendation: Update the CI optimization documentation to reflect the temporary reversion to Node 20 only, with a note about re-enabling Node 22 when the upstream bug is resolved.

3. Changelog Consideration ℹ️ INFO

Per CLAUDE.md, user-visible changes should be documented in CHANGELOG.md. Since this is a temporary CI-only change that doesn't affect end users of the gem, a changelog entry is likely not required. However, if this stays for a release cycle, consider adding a note about Node 20 being the tested version.

Performance Considerations: ✅ Good

  • Restoring yarn caching will significantly improve CI performance compared to the empty cache approach
  • Node 20 is stable and well-tested for this project
  • No performance regressions expected

Security Concerns: ✅ None

  • Node 20 is actively maintained and receives security updates
  • No security-related changes in this PR

Test Coverage: ⚠️ NEEDS ATTENTION

From PR description:

  • RuboCop passes locally
  • Git hooks pass
  • CI workflows pass - THIS SHOULD BE VERIFIED BEFORE MERGE

Missing:

  • No indication that the Pro workflows were tested
  • The PR should verify that all CI workflows complete successfully

Best Practices & Conventions: ✅ Excellent

  • Follows the project's workflow patterns
  • Good commit message format
  • Proper attribution with Claude Code
  • References upstream issue tracker

Recommendations

Must Fix Before Merge:

  1. Update all Pro workflow files to use Node 20 with proper caching
  2. Verify all CI workflows pass (including Pro workflows if accessible)

Should Fix:

  1. Update CI_OPTIMIZATION.md to reflect current Node version strategy
  2. Update CI_OPTIMIZATION_SUMMARY.md if it contains similar outdated examples

Consider:

  1. Add a TODO comment in workflow files linking to the Node.js issue for easy tracking when the bug is resolved
  2. Consider adding a GitHub Actions job that validates all workflow files use consistent Node versions

Code Suggestions

For the Pro workflow files, apply similar changes:

- node-version: 22
- # TODO: Re-enable cache when Node.js 22 V8 bug is fixed
- # Disable cache for Node 22 due to V8 bug in 22.21.0
- # Track: https://github.com/nodejs/node/issues/56010
- cache: ''
+ node-version: 20
+ cache: 'yarn'

Summary

This is a well-intentioned fix that correctly addresses the immediate CI failures in the main workflows. However, it's incomplete - the Pro workflows still have the problematic configuration and will continue to fail. The documentation also needs updating to match the new reality.

The approach of reverting to Node 20 is pragmatic and correct given the upstream bug. Once all workflows are consistently updated and the documentation is corrected, this will be a solid fix.

Recommendation: Request changes to address the Pro workflows and documentation before merging.


Review generated with assistance from Claude Code

@claude
Copy link

claude bot commented Nov 5, 2025

Code Review

Summary

This PR addresses CI failures by reverting workflows from Node.js 22 to Node 20 due to a V8 caching bug. The approach is pragmatic and well-documented.

✅ Strengths

  1. Clear Rationale: The PR description clearly explains why the reversion is necessary and links to the upstream Node.js issue (#56010).

  2. Comprehensive Fix: All three workflow files are updated consistently:

    • lint-js-and-ruby.yml
    • main.yml
    • package-js-tests.yml
  3. Simplification: Removes complex conditional logic (matrix.node-version != '22' && 'yarn' || '') in favor of straightforward configuration.

  4. Good Documentation: Comments reference the specific Node.js issue for future tracking.

🔍 Code Quality Observations

Positive:

  • Consistent approach across all workflow files
  • Removes fragile conditional logic that was causing GitHub Actions failures
  • Maintains cache functionality properly with cache: 'yarn'

Minor Considerations:

  1. Matrix Simplification in package-js-tests.yml:

    # Before: matrix with two versions (20, 22)
    # After: matrix with single version [20]

    Using a matrix for a single value is valid but slightly redundant. Consider whether to:

    • Keep the matrix for easier future expansion ✅ (current approach)
    • Remove the matrix entirely and use a single node-version value
  2. Test Condition Removal:
    The if: matrix.node-version == '20' condition was removed from the conversion script step in package-js-tests.yml. This is correct since only Node 20 runs now, but ensure the conversion script works properly with Node 20.

  3. Frozen Lockfile Flag:
    The conditional ${{ matrix.node-version == '22' && '--frozen-lockfile' || '' }} was removed. This is fine, but consider whether --frozen-lockfile should be used consistently for CI to catch lockfile issues:

    yarn install --no-progress --no-emoji --frozen-lockfile

🎯 Best Practices

GitHub Actions: Proper use of setup-node with explicit cache configuration
Consistency: All workflows updated uniformly
Documentation: Clear comments explaining the temporary nature of the change

🔐 Security

No security concerns identified.

🧪 Test Coverage

The PR mentions test plan items:

  • ✅ RuboCop passes locally
  • ✅ Git hooks pass
  • ⏳ CI workflows pass (pending)

📝 Suggestions

  1. Consider adding a TODO or tracking issue in the project to remember to re-enable Node.js 22 once the upstream bug is fixed. Something like:

    # TODO: Upgrade back to Node 22 when V8 bug is resolved
    # Track: https://github.com/nodejs/node/issues/56010
    node-version: 20
  2. Optional: Add --frozen-lockfile to yarn install in CI for stricter dependency checking:

    yarn install --no-progress --no-emoji --frozen-lockfile
  3. Monitor the upstream issue to know when it's safe to upgrade back to Node 22.

🎬 Conclusion

Recommendation: ✅ APPROVE

This is a pragmatic fix that addresses immediate CI failures while maintaining clean, readable workflow configurations. The reversion to Node 20 is well-justified and properly documented. The simplification of conditional logic is a welcome improvement.

The changes align with the project's CI needs and follow GitHub Actions best practices. Once CI passes, this should be safe to merge.


🤖 Review generated with Claude Code

@claude claude bot mentioned this pull request Nov 5, 2025
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants