docs: record the npm cache failure and fix two broken release checks#335
docs: record the npm cache failure and fix two broken release checks#335arifulhoque7 wants to merge 1 commit into
Conversation
The v2.4.0 deploy failed on a transient npm _cacache collision in the Install and build step, then went green on a rerun. Document it so the next release does not lose time re-diagnosing it, and fix two checks in the pre-release block that were giving wrong answers. - Document the EEXIST/ENOENT _cacache signature, why setup-node's npm cache always misses on a release commit (the version bump changes the lockfile hash), and that a rerun is safe because the step fails upstream of the disk-gate, zip, Release and SVN deploy. Call out the EBADENGINE warnings as red herrings that appear in green runs too. - Derive the previous tag by creatordate instead of sort -V. A stray v2.11.12 tag from 2025-07-24 sorts above v2.3.1 and silently made every diff compare against the wrong baseline. - Match the BUILD_DIR check to the YAML key. A bare grep also matched the warning comment above the 10up step, so the check false-failed every run. - Note that the versioned wp.org zip returns HTTP 200 with a "Not found" body until it is generated, which reads as a broken release. - Update the last-known-good release to v2.4.0, now that the untracked-build and 10up-sole-publisher pipeline is proven.
WalkthroughUpdated the release skill documentation for tag selection, deploy validation, npm cache failures, SVN verification, and release-history facts. ChangesRelease Pipeline Guidance
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/wedocs-release/SKILL.md:
- Around line 39-53: Update the mandatory verification checks in the release
skill to fail closed: replace the `grep ... && echo` checks for tracked
`assets/build`, missing `block_directories` or block entries, missing
`block-styles.php`, and workflow `BUILD_DIR` input with explicit conditional
checks that print the existing failure message and exit 1. Keep the Tailwind
check as a warning and preserve the final diff command.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c4fcc11c-89b3-48dc-9906-a4349128c473
📒 Files selected for processing (1)
.claude/skills/wedocs-release/SKILL.md
| # 1. assets/build must be UNTRACKED now (10up builds + ships it from CI). | ||
| git ls-files assets/build | grep -q . && echo "FAIL: assets/build is tracked — untrack it (git rm -r --cached assets/build)" | ||
| # 2. register_blocks() must still have the full block list (security cleanups love to delete it) | ||
| grep -q 'block_directories' wedocs.php || echo "FAIL: register_blocks gutted" | ||
| grep -c 'assets/build/blocks/' wedocs.php # expect ~17-19 entries, not 1 | ||
| # 3. the block-styles helper require must be intact | ||
| grep -q "blocks/helpers/block-styles.php" wedocs.php || echo "FAIL: block-styles require missing" | ||
| # 4. NO BUILD_DIR in the deploy workflow | ||
| grep -q 'BUILD_DIR' .github/workflows/deploy-org.yml && echo "FAIL: BUILD_DIR present — it strips the untracked build" | ||
| # 4. NO BUILD_DIR *input* in the deploy workflow. Match the YAML key only — a bare | ||
| # `grep BUILD_DIR` also matches the warning COMMENT above the 10up step and | ||
| # false-fails every single time. | ||
| grep -qE '^\s*BUILD_DIR\s*:' .github/workflows/deploy-org.yml && echo "FAIL: BUILD_DIR present — it strips the untracked build" | ||
| # 5. tailwind.config.js must be the clean ESM import form | ||
| head -6 tailwind.config.js | grep -q "^import {" || echo "WARN: tailwind not ESM-import form" | ||
| # 6. diff the two files security-cleanups have damaged before | ||
| git --no-pager diff "v$PREV" -- wedocs.php tailwind.config.js |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Make mandatory checks fail closed.
These commands only print FAIL/WARN; they never terminate the script. Without explicit exit 1, a tracked assets/build or present BUILD_DIR can pass through the “mandatory” verification and continue toward release.
Use explicit if checks with exit 1 for hard failures; do not rely on grep ... && echo.
Proposed pattern
+set -euo pipefail
+
-if git ls-files assets/build | grep -q . && echo "FAIL: assets/build is tracked — untrack it (git rm -r --cached assets/build)"
+if git ls-files assets/build | grep -q .; then
+ echo "FAIL: assets/build is tracked — untrack it (git rm -r --cached assets/build)" >&2
+ exit 1
+fi🧰 Tools
🪛 SkillSpector (2.3.11)
[error] 133: [TM1] Tool Parameter Abuse: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Remediation: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
(Tool Misuse (TM1))
[error] 40: [TM1] Tool Parameter Abuse: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Remediation: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
(Tool Misuse (TM1))
[error] 133: [TM1] Tool Parameter Abuse: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Remediation: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
(Tool Misuse (TM1))
[error] 141: [TM1] Tool Parameter Abuse: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Remediation: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
(Tool Misuse (TM1))
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/skills/wedocs-release/SKILL.md around lines 39 - 53, Update the
mandatory verification checks in the release skill to fail closed: replace the
`grep ... && echo` checks for tracked `assets/build`, missing
`block_directories` or block entries, missing `block-styles.php`, and workflow
`BUILD_DIR` input with explicit conditional checks that print the existing
failure message and exit 1. Keep the Tailwind check as a warning and preserve
the final diff command.
1 participant
Follow-up to the v2.4.0 release, which failed once then went green on a rerun.
The failure
Install and builddied atnpm ci:ENOENTon the temp file andFile existson the destination = corrupt npm_cacache, not a dependency problem. The workflow was unchanged since before v2.3.1 andpackage-lock.jsonwas identical apart from the version bump.setup-node'scache: 'npm'keys off the lockfile hash. The release commit bumps the version inside the lockfile, so a release tag always misses the key, restores a partial cache viarestore-key, andnpm cicollides with it.Safe to rerun — it fails upstream of the disk-gate, zip, Release and SVN deploy, so nothing is published.
Two checks that were lying
LAST=... sort -V | tail -1v2.11.12(2025-07-24) sorts abovev2.3.1→ every diff used the wrong baselinecreatordategrep -q 'BUILD_DIR'^\s*BUILD_DIR\s*:Verified: date-sort now yields
v2.4.0 v2.3.1; the BUILD_DIR check passes.Also
Not founduntil generated — looks like a broken release.Docs only —
.claudeis excluded via.distignore, so nothing ships.Summary by CodeRabbit