From 249da74f184b4d6e4e21420a1a94179434fb95f6 Mon Sep 17 00:00:00 2001 From: Andrew Mikofalvy <5668128+amikofalvy@users.noreply.github.com> Date: Fri, 16 Oct 2026 03:55:08 +0000 Subject: [PATCH] PRD-9471 Retry every pnpm/setup download once (#6517) * PRD-9471 Retry every pnpm/setup download once pnpm/setup fetches pnpm from registry.npmjs.org once through get-pnpm, which has no retry, so one registry stall failed the job. Between 2026-10-09 and 10-14 that failed OK Cloud Pilot's desktop-release (run 38617662424), Mirror Runnability (run 38513928002) and the required open-knowledge / test:fidelity cell (run 38460806488, which hung for ten minutes first). Every pnpm/setup call site in every tree now runs the shape already on research/ok-cloud (#6499): a first attempt bounded at 2 minutes that continues on error, a 20 second wait, one retry with the same inputs and no continue-on-error, and a step that records whether the retry recovered or was exhausted. Workflows that run on merge_group, the reusable _subtree-validation.yml and the composite actions do not retry on merge_group, matching the checkout retry there. Composite actions cannot bound a step, so their attempts are unbounded. The validation test matrix declares 4 more minutes of setup in its retry budgets, which moves the default cell cap from 15 to 16, and the cap-verdict gate goes from 5 to 8 minutes so a recovered first attempt still fits its slowest green run. scripts/check-pnpm-setup-retry.test.mjs pins every site and runs the shipped wait and record scripts. The guards that refuse continue-on-error accept a first attempt only while its retry does not continue on error. * PRD-9471 Address review of the pnpm/setup retry The runbook gets an entry for a failed pnpm/setup download: what the started, recovered and exhausted annotations mean, to check the packageManager pin before re-running after exhausted, and that a merge_group failure is a re-enqueue. The architecture paragraph links it, and the test-cap sentence there now points at the workflow instead of repeating the old default of 15. The Windows desktop composite's README lists the eleven steps the action now runs and says pnpm is retried once outside merge_group, bounded only by the caller's 12 minutes. That bound still covers a recovered retry on top of the measured 3m52s; a first attempt that hangs past it ends there with no retry, as before, and raising it to cover a long hang would crowd the shard cell's 30-minute cap. check-pnpm-setup-retry.test.mjs gets a read edge over every .github YAML file, so a workflow-only push selects it at pre-push. auto-format-selection.test.mjs now exempts only the wait, retry and record steps, matched by name and their exact if, so a condition such as "steps.pnpm-setup.outcome == 'failure' || true" no longer passes the select gate. * PRD-9471 Correct the Windows composite docs after the pnpm retry The runbook's pnpm entry now links the checkout entry by anchor instead of pointing "above" at text 800 lines below. The action description, the crossbuild runbook entry and the selector test comment no longer give the composite a step count, which the retry made stale. The README's late-failure example now says what that run would do here: the retry starts at about 10m20s and the caller's 12-minute bound cuts it or the later steps off. * PRD-9471 Drop the stale step count from the Windows composite callers The two comments above the setup-ok-windows-desktop calls still said the composite runs eight setup steps; the retry made it eleven, and they now give no count, like the other three sites. GitOrigin-RevId: ef7915654423b131cbfc0c53e8ff445c6b3d1ef6 --- .github/workflows/release.yml | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 0bdbdc8..b8e1809 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -44,10 +44,37 @@ jobs: with: fetch-depth: 0 - - name: Setup pnpm + - name: Installing pnpm + id: pnpm-setup uses: pnpm/setup@84cb39b217b10273981911c288cd62326dc7c6d2 # v2.0.2 + continue-on-error: true + timeout-minutes: 2 with: install: false + - name: Waiting before retrying the pnpm download + if: steps.pnpm-setup.outcome == 'failure' + shell: bash + run: | + echo "::warning::pnpm-setup-retry=started. The first pnpm/setup attempt failed or hit its 2-minute bound; its error is in the Installing pnpm step. Retrying once in 20s." + sleep 20 + - name: Installing pnpm (retry after a failed download) + id: pnpm-setup-retry + if: steps.pnpm-setup.outcome == 'failure' + uses: pnpm/setup@84cb39b217b10273981911c288cd62326dc7c6d2 # v2.0.2 + timeout-minutes: 2 + with: + install: false + - name: Recording the pnpm download retry result + if: ${{ !cancelled() && steps.pnpm-setup.outcome == 'failure' }} + shell: bash + env: + RETRY_OUTCOME: ${{ steps.pnpm-setup-retry.outcome }} + run: | + if [[ "$RETRY_OUTCOME" == success ]]; then + echo "::notice::pnpm-setup-retry=recovered. The first pnpm/setup attempt failed and the retry installed pnpm." + else + echo "::error::pnpm-setup-retry=exhausted retry=${RETRY_OUTCOME}. Both pnpm/setup attempts failed; their errors are in the two Installing pnpm steps." + fi - name: Setup Node for OIDC publishing uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6