fix(actions): stop a killed npm upgrade wedging an agent for good - #8
Merged
Merged
Conversation
`npm i -g npm` renames the live npm directory aside to `.npm-<suffix>` before unpacking the new one. The suffix is derived from the path, not random, so an install killed part-way leaves that directory behind and every later install on the same agent fails the rename with ENOTEMPTY. The agent stays broken until someone deletes it by hand -- prosvr8-3 sat like that from 2026-09-24 and failed this step on every job it picked up. Skip the install when npm is already the pinned version, which on a self-hosted agent is every run after the first, and sweep any leftover staging directory before installing for the agents already holding one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was broken
Every job that landed on the self-hosted agent
prosvr8-3failed at theinstall npmstep with exit code 217:4 of the last 12 failed runs on Protect were this. All of them that one agent.
Why
npm i -g npmupgrades npm by renaming the livenode_modules/npmdirectory out of the way to.npm-<suffix>, then unpacking the new copy in its place. That suffix comes from the path, not from a random number.So when an upgrade gets killed part-way — a cancelled run, an agent restart — it leaves the half-copied
.npm-<suffix>directory sitting there. The next upgrade picks the same name, and renaming onto a non-empty directory isENOTEMPTY. Every time. The agent is broken until someone SSHes in and deletes it by hand.prosvr8-3had one dated 2026-09-24 12:12 and failed this step on every job it picked up for a day. (Already cleared by hand, so CI is unblocked; this PR stops it happening again.)The sting: npm on that agent was already 11.6.2. The step was reinstalling a version it already had, and wedging itself doing it.
What changed
npm -valready matches the pin. On a self-hosted agent that is every run after the first, so the rename that causes this never happens. Also saves ~10s per job..npm-*staging directory before installing, for agents already holding one.env:var, with the [BUG] npm@11.6.3 fails to install withoverrideshavingnpm error Cannot read properties of undefined (reading 'ruleset')npm/cli#8757 pin reason next to it instead of in a trailing comment.Test coverage
No tests in this repo. Verified directly against the real agent:
npm prefix -gresolves to the toolcache root, so the sweep path ($(npm prefix -g)/lib/node_modules/.npm-*) is the right directory..npm-*matching nothing is a no-op underrm -rf.npm@step now reportssuccess.🤖 Generated with Claude Code