Add CI workflow to check assets:precompile output for failures #2134
Conversation
Closes #2081 This adds a new GitHub Actions workflow that runs `RAILS_ENV=production bin/rake assets:precompile` on the dummy app and checks the output for known failure patterns: - Duplicate webpack compilations (tasks running twice) - Duplicate rake task execution (e.g., generate_packs running multiple times) - Module not found / cannot resolve errors - Webpack compilation errors - Ruby errors (NameError, LoadError, etc.) - Asset pipeline errors - Memory issues (heap out of memory) - High warning counts (>10 warnings triggers a warning annotation) The workflow runs on PRs and master pushes, uses the same change detection as other CI jobs, and uploads the precompile output as an artifact for debugging when failures occur. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
Warning Rate limit exceeded@justin808 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 2 minutes and 50 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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. 📒 Files selected for processing (1)
WalkthroughA new GitHub Actions workflow validates asset precompilation in CI. The workflow detects changes to determine execution scope, runs Changes
Sequence DiagramsequenceDiagram
actor Trigger as Workflow Trigger<br/>(push/dispatch)
participant GHA as GitHub Actions
participant DC as detect-changes Job
participant PC as precompile-check Job
participant Setup as Env Setup<br/>(Ruby/Node/pnpm)
participant ROR as react-on-rails<br/>Publishing
participant Rails as Rails App
participant Scanner as Failure Scanner
Trigger->>GHA: Workflow triggered
GHA->>DC: Run change detection
DC->>DC: Check full-CI label<br/>Evaluate base ref & PR changes
DC-->>GHA: Output: docs_only,<br/>run_dummy_tests,<br/>has_full_ci_label
alt Master docs-only push
GHA->>GHA: Skip precompile-check
else Proceed with checks
GHA->>PC: Run precompile-check
PC->>Setup: Setup Ruby/Node/pnpm
Setup-->>PC: ✓ Environments ready
PC->>ROR: Publish & link<br/>react-on-rails via yalc
ROR-->>PC: ✓ Published
PC->>Rails: Prepare dummy app
Rails-->>PC: ✓ Dependencies installed
PC->>Rails: Execute assets:precompile
Rails-->>PC: Precompile output
PC->>Scanner: Scan for failure patterns
alt Pattern matched
Scanner-->>GHA: ⚠️ Error annotation
Scanner-->>GHA: ❌ Step fails
else No patterns detected
Scanner-->>GHA: ✓ Precompile valid
end
PC->>GHA: Upload precompile_output.txt
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30–40 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
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. Comment |
Code Review for PR #2134: Assets Precompile Check WorkflowI've reviewed this PR against the repository's CLAUDE.md guidelines and best practices. Overall, this is a well-structured addition that addresses a real pain point (issue #2081). Here's my detailed feedback: ✅ Strengths1. Excellent Problem Alignment
2. Consistent with Existing CI Patterns
3. Good Error Detection CoverageThe 8 failure patterns cover realistic scenarios:
4. Helpful Debugging Features
🔍 Issues & Suggestions1. Critical: Logic Error in Duplicate Compilation Detection (Lines 148-159)Current code: WEBPACK_COMPILE_COUNT=$(grep -c "Compiled" precompile_output.txt || true)
if [ "$WEBPACK_COMPILE_COUNT" -gt 1 ]; then
DUPLICATE_COMPILES=$(sort precompile_output.txt | uniq -d | grep -c "Compiled" || true)
if [ "$DUPLICATE_COMPILES" -gt 0 ]; then
echo "::error::FAILURE: Detected duplicate webpack compilations..."Problem: Example that would NOT be detected: Recommended fix: # Count how many times the word "Compiled" appears in the output
WEBPACK_COMPILE_COUNT=$(grep -c "Compiled" precompile_output.txt || true)
# If we see "Compiled" more than once, it's likely a duplicate execution
# (Shakapacker typically only compiles once during assets:precompile)
if [ "$WEBPACK_COMPILE_COUNT" -gt 1 ]; then
echo "::error::FAILURE: Detected $WEBPACK_COMPILE_COUNT webpack compilations (expected 1)."
echo " This may indicate rake tasks are running multiple times."
FAILURES_FOUND=1
fi2. Minor: Possible Path Inconsistency (Line 116)Lines 116, 118, 132, and 225 use Verification needed: Check if 3. Enhancement: Add Exit Code Check (After Line 139)The current script only checks patterns in the output, but doesn't verify that Recommended addition: # Run precompile and capture exit code
RAILS_ENV=production bin/rake assets:precompile 2>&1 | tee precompile_output.txt
PRECOMPILE_EXIT_CODE=${PIPESTATUS[0]}
if [ $PRECOMPILE_EXIT_CODE -ne 0 ]; then
echo "::error::FAILURE: rake assets:precompile exited with status $PRECOMPILE_EXIT_CODE"
exit $PRECOMPILE_EXIT_CODE
fi4. Minor: Overly Broad Ruby Error Detection (Lines 183-186)Current: if grep -Ei "NameError|LoadError|NoMethodError|SyntaxError" precompile_output.txt; thenIssue: This could trigger false positives from comments, logs, or handled exceptions. Recommended refinement: # Look for actual error traces, not just the word "Error"
if grep -E "^[[:space:]]*(NameError|LoadError|NoMethodError|SyntaxError):" precompile_output.txt; then
echo "::error::FAILURE: Ruby errors detected during precompile."
FAILURES_FOUND=1
fiThis anchors the pattern to error message format, reducing false positives. 5. Enhancement: Show Matching Lines on FailureWhen a pattern matches, showing which lines matched would aid debugging: if grep -Ei "module not found|cannot find module|can't resolve" precompile_output.txt; then
echo "::error::FAILURE: Module resolution errors detected in precompile output."
echo "Matching lines:"
grep -Ei "module not found|cannot find module|can't resolve" precompile_output.txt | head -10
FAILURES_FOUND=1
fi🛡️ Security Considerations✅ No security concerns identified:
🧪 Test Coverage RecommendationsRecommended test plan:
📋 Adherence to CLAUDE.md Guidelines✅ Follows change detection pattern from existing workflows 🎯 Overall AssessmentQuality: High Required Changes:
Optional Enhancements:
Great work on this defensive CI addition! Once the duplicate detection logic is fixed, this will be a valuable safeguard against infrastructure regressions. |
The precompile check needs to run react_on_rails:generate_packs first to generate the server-bundle-generated.js file that webpack imports. This matches what other CI jobs do before running webpack builds. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (4)
.github/workflows/precompile-check.yml (4)
163-170: Add context to task duplication error for debugging.When
react_on_rails:generate_packsis detected running multiple times, the error message (line 167) only shows the count, not the actual lines or execution order. This makes it harder to understand what triggered the duplication.# Pattern 2: Duplicate task execution messages if grep -q "react_on_rails:generate_packs" precompile_output.txt; then GENERATE_PACKS_COUNT=$(grep -c "react_on_rails:generate_packs" precompile_output.txt || true) if [ "$GENERATE_PACKS_COUNT" -gt 1 ]; then echo "::error::FAILURE: react_on_rails:generate_packs task ran $GENERATE_PACKS_COUNT times (should only run once)." + echo " Matching lines:" + grep -n "react_on_rails:generate_packs" precompile_output.txt FAILURES_FOUND=1 fi fi
172-176: Add context to module resolution error for debugging.When module resolution errors are detected, only a generic message is shown. Including sample matching lines makes it easier to triage issues in CI.
# Pattern 3: Module not found errors if grep -Ei "module not found|cannot find module|can't resolve" precompile_output.txt; then echo "::error::FAILURE: Module resolution errors detected in precompile output." + echo " Sample matching lines:" + grep -Ei "module not found|cannot find module|can't resolve" precompile_output.txt | head -3 FAILURES_FOUND=1 fi
190-194: Sprockets error pattern could be case-sensitive mismatch.The pattern
"sprockets::filenotfound"(line 191) uses lowercase, but actual Ruby exception class names typically follow PascalCase (e.g.,Sprockets::FileNotFound). While-Eimakes the grep case-insensitive, the class name would be more clearly matched with the proper casing shown in the pattern.- if grep -Ei "sprockets::filenotfound|asset .* was not declared" precompile_output.txt; then + if grep -Ei "Sprockets::FileNotFound|Asset.*was not declared" precompile_output.txt; then echo "::error::FAILURE: Asset pipeline errors detected." + echo " Sample matching lines:" + grep -Ei "Sprockets::FileNotFound|Asset.*was not declared" precompile_output.txt | head -3 FAILURES_FOUND=1 fi
202-206: Warning count detection uses case-insensitive match; clarify intent or adjust threshold.The pattern
grep -ci "warning"matches any line containing "warning" (case-insensitive). This could include false positives from messages like "This is a warning to users" or unrelated logging. The threshold of >10 warnings is also arbitrary and may not reflect actual build health.Consider narrowing the pattern to specific warning types (e.g., webpack or Rails deprecation warnings) or document the current threshold choice:
# Pattern 8: Check for warnings that might indicate problems - WARNING_COUNT=$(grep -ci "warning" precompile_output.txt || true) + # Count webpack/build warnings (case-insensitive to catch "Warning:" and similar) + WARNING_COUNT=$(grep -Ei "warning|warn" precompile_output.txt | grep -v "User warning" | wc -l || true) if [ "$WARNING_COUNT" -gt 10 ]; then - echo "::warning::High number of warnings detected: $WARNING_COUNT warnings found. Please review." + echo "::warning::High number of build warnings detected: $WARNING_COUNT warnings found. Please review." + echo " Sample warnings:" + grep -Ei "warning|warn" precompile_output.txt | grep -v "User warning" | head -3 fiThis helps distinguish build warnings from other logged text.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/precompile-check.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T08:05:17.804Z
Learning: Applies to lib/react_on_rails/*.rb : Create RBS signature files for new Ruby files in `lib/react_on_rails/` by adding corresponding `.rbs` file in `sig/react_on_rails/`, adding to Steepfile, and validating before committing
Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T08:05:17.804Z
Learning: The `react_on_rails_pro/` directory has its own Prettier/ESLint configuration and must be linted separately
⏰ 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). (9)
- GitHub Check: dummy-app-integration-tests (3.4, 22, latest)
- GitHub Check: examples (3.4, latest)
- GitHub Check: build
- GitHub Check: pro-lint-js-and-ruby
- GitHub Check: precompile-check
- GitHub Check: build-dummy-app-webpack-test-bundles
- GitHub Check: rspec-package-tests (3.4, latest)
- GitHub Check: build-dummy-app-webpack-test-bundles
- GitHub Check: claude-review
🔇 Additional comments (1)
.github/workflows/precompile-check.yml (1)
222-228: Artifact configuration is sound for CI diagnostics.The artifact upload uses
if: always()to ensure logs are captured even on failure, includes a run-specific ID for uniqueness, and sets a reasonable 7-day retention window. This is good practice for debugging precompile failures.
The dummy app uses ReScript components that need to be compiled before webpack can bundle them. This adds `pnpm run build:rescript` to compile HelloWorldReScript.res.js and other ReScript files. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Changes based on CodeRabbit review comments: 1. Capture rake exit code with PIPESTATUS to detect silent failures - Added set -o pipefail to propagate pipe failures - Check PIPESTATUS[0] after tee to catch rake failures 2. Improved duplicate webpack compilation detection - Changed pattern from generic "Compiled" to "Compiled successfully" - Simplified logic to count successful compilations directly - Added line numbers to matching output for debugging 3. Improved webpack error pattern detection - Changed from overly broad "error in" to more specific patterns - Now matches: webpack.*error, failed to compile, compilation failed, ERROR in 4. Better Ruby error detection - Pattern now matches error class format with colon (e.g., "NameError:") - Reduces false positives from log messages 5. Fixed asset pipeline error pattern - Use proper casing for Sprockets::FileNotFound 6. Added sample output for all error patterns - Each error now shows the first few matching lines for easier debugging 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Code Review: Assets Precompile Check WorkflowI've reviewed PR #2134 and overall this is a well-implemented and valuable addition to the CI pipeline. The workflow effectively addresses the issue of detecting silent failures during asset precompilation. Below are my findings: ✅ Strengths1. Excellent Pattern Detection StrategyThe workflow checks for 8 critical failure patterns that have caused production issues:
This comprehensive approach will catch both obvious and subtle failures. 2. Proper CI Integration
3. Good Error Handling
4. Helpful Debugging Features
🔍 Areas for Improvement1. Potential False Positives in Pattern DetectionIssue: Some patterns might be too broad and trigger false positives. Pattern 3 (lines 185-190): Module errorsgrep -Ei "module not found|cannot find module|can't resolve"Concern: This could match warnings in addition to actual errors. Webpack often emits deprecation warnings that contain these phrases but don't fail the build. Suggestion: Consider adding context to ensure these are actual errors: if grep -Ei "(ERROR|error).*module not found|(ERROR|error).*cannot find module|(ERROR|error).*can't resolve" precompile_output.txt; thenPattern 4 (lines 193-198): Webpack errorsgrep -Ei "webpack.*error|failed to compile|compilation failed|ERROR in"Concern: Suggestion: Use more specific patterns: grep -Ei "webpack.*ERROR|ERROR in [./]|compilation failed|failed to compile" precompile_output.txt2. Warning Threshold May Need TuningLine 226: Question: Is 10 warnings an appropriate threshold for this codebase? Suggestion:
3. Missing Pattern: Build Timeout/Hung ProcessesObservation: The workflow doesn't have a timeout specified for the precompile step. Risk: If webpack hangs, the job could run for the default 6-hour timeout. Suggestion: Add a timeout to the precompile step: - name: Run assets:precompile and check output
timeout-minutes: 20 # or whatever is reasonable
run: |4. Pattern Validation: Empty MatchesLines 163-230: Several patterns use Potential Issue: If Observation: Line 144 uses 5. Documentation: What Each Pattern PreventsSuggestion: Add comments above each pattern explaining which past incident it prevents: # Pattern 1: Prevents duplicate webpack compilations (regression test for PR #2052)
# Context: Rails::Engine was loading rake tasks twice, causing duplicate builds
if grep -q "Compiled successfully" precompile_output.txt; then
...
fiThis helps future maintainers understand why each check exists. 🔒 Security Considerations✅ No security concerns identified:
🎯 Performance ConsiderationsGood:
Minor:
🧪 Test CoverageFrom PR description test plan:
Suggestion: After merge, consider creating a follow-up issue to:
This validates the detection logic comprehensively. 📋 Checklist for MergeBefore merging, verify:
🎓 Alignment with Project GuidelinesChecked against ✅ Follows CI/CD patterns: Uses standard References:
✨ Final VerdictAPPROVED with minor suggestions ✅ This PR effectively solves the problem stated in issue #2081. The workflow is well-structured, follows existing patterns, and will catch critical production issues. The suggestions above are non-blocking improvements that can be addressed in follow-up PRs or ignored if the current implementation proves robust in practice. Recommended next steps:
Great work! This will significantly improve build reliability. 🚀 Review performed by Claude Code following project standards from CLAUDE.md |
Summary
Closes #2081
This adds a new GitHub Actions workflow that runs
RAILS_ENV=production bin/rake assets:precompileon the dummy app and checks the output for known failure patterns that have been encountered in the past.Failure Patterns Detected
The workflow checks for:
generate_packsrunning multiple timesFeatures
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.