ci: fail loudly when pnpm install exhausts its retries #480

Merged
gmackie merged 1 commit from ci/fail-loud-on-install-failure into main 2026-08-27 00:40:15 +00:00
Owner

Both pnpm install --frozen-lockfile retry loops passed the step even when all three attempts failed. A for loop's exit status is its last command — here the trailing sleep 10 — so a total install failure reported success and the next step ran against an empty node_modules.

The symptom is a lie

#340 has failed three times with:

sh: 1: storybook: not found

which says nothing about the cause. Storybook builds fine locally on both that branch and main, and pnpm install --frozen-lockfile succeeds on both. So the install was failing in CI for network reasons — exactly what the retry loop exists for — and then hiding it behind a downstream error that sent me looking at storybook, lockfiles, and workspace globs instead.

The fix is already in this file

The gitleaks download above tracks an ok flag and exits 1 when retries are exhausted, with a comment that puts it better than I can:

the one outcome worse than a noisy gate is one that skips quietly

The deploy health checks guard themselves too. Only these two loops did not.

Verified

Ran the shapes directly: the old form exits 0 when every attempt fails, the new form exits 1, and still exits 0 when the first attempt succeeds.

Both `pnpm install --frozen-lockfile` retry loops **passed the step even when all three attempts failed**. A `for` loop's exit status is its last command — here the trailing `sleep 10` — so a total install failure reported success and the next step ran against an empty `node_modules`. ## The symptom is a lie #340 has failed three times with: ``` sh: 1: storybook: not found ``` which says nothing about the cause. Storybook builds fine locally on **both** that branch and main, and `pnpm install --frozen-lockfile` succeeds on both. So the install was failing in CI for network reasons — exactly what the retry loop exists for — and then hiding it behind a downstream error that sent me looking at storybook, lockfiles, and workspace globs instead. ## The fix is already in this file The gitleaks download above tracks an `ok` flag and exits 1 when retries are exhausted, with a comment that puts it better than I can: > the one outcome worse than a noisy gate is one that skips quietly The deploy health checks guard themselves too. Only these two loops did not. ## Verified Ran the shapes directly: the old form exits **0** when every attempt fails, the new form exits **1**, and still exits 0 when the first attempt succeeds.
ci: fail loudly when pnpm install exhausts its retries
All checks were successful
CI / gitleaks (pull_request) Successful in 6s
CI / storybook (pull_request) Successful in 1m39s
forgegraph/ci CI passed
CI / ci (pull_request) Successful in 9m19s
8e12714ff5
Both `pnpm install --frozen-lockfile` retry loops passed the step even when
all three attempts failed. A `for` loop's exit status is its last command —
here the trailing `sleep 10` — so a total install failure reported success
and the next step ran against an empty node_modules.

The symptom is a lie. #340 has failed three times with

    sh: 1: storybook: not found

which says nothing about the cause. Storybook builds fine locally on both
that branch and main, and `pnpm install --frozen-lockfile` succeeds on both,
so the install was failing in CI for network reasons — exactly what the retry
loop exists for — and then hiding it behind a downstream error.

The correct pattern is already in this file: the gitleaks download above
tracks an `ok` flag and exits 1 when the retries are exhausted, with a
comment that puts it better than I can — "the one outcome worse than a noisy
gate is one that skips quietly." The deploy health checks guard themselves
too. Only these two loops did not.

Verified the shapes directly: the old form exits 0 when every attempt fails,
the new form exits 1, and still exits 0 when the first attempt succeeds.
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
gmackie/ForgeGraph!480
No description provided.