fix: wait longer for npm in drift

Author: drptbl

.github/workflows/drift.yml

@@ -34,8 +34,8 @@ jobs:
   build:
     runs-on: ubuntu-latest
     # The 3.0.0 build took just under six minutes on a laptop. The rest is room for the pin
-    # step's wait of up to 15 minutes for npm, for uv, and for the wiki API's retries.
-    timeout-minutes: 60
+    # step's wait of up to 45 minutes for npm, for uv, and for the wiki API's retries.
+    timeout-minutes: 90
     # It runs the generator over content anyone can edit, so it can only read.
     permissions:
       contents: read
@@ -76,7 +76,7 @@ jobs:
           require-lockfile: true
       # The server this run builds and tests the index with, before the generator runs: the version
       # a server-release dispatch asks for, or the newest npm lists, as scripts/server-pin.ts
-      # decides. A move waits up to 15 minutes, checking every 30 seconds, until npm lists the
+      # decides. A move waits up to 45 minutes, checking every 30 seconds, until npm lists the
       # version and its tarball answers, since pnpm add fails on a version npm does not serve yet.
       # The step holds no token. The dispatch's version is data, checked whole before any use. The
       # hashes of the two manifests let the pr job require the ones this job built index.db with.
@@ -118,7 +118,7 @@ jobs:
               # How often and how long the wait polls, from the environment so the tests can
               # shorten them.
               poll=${POLL_SECONDS:-30}
-              limit=${DEADLINE_SECONDS:-900}
+              limit=${DEADLINE_SECONDS:-2700}
               for value in "$poll" "$limit"; do
                 if [[ ! $value =~ ^[0-9]+$ ]]; then
                   echo "Not a whole number of seconds: '$value'" >&2

docs/MAINTAINING.md

@@ -149,7 +149,7 @@ Before the generator runs, its `Pin the server` step decides which server builds
 - Any other run moves the pin to the version npm lists as `latest` when that is above the pin,
   so a release whose dispatch was lost is picked up by the next scheduled run.
 
-A move waits up to 15 minutes, checking every 30 seconds, until `npm view` lists the version's
+A move waits up to 45 minutes, checking every 30 seconds, until `npm view` lists the version's
 tarball and a `HEAD` on it answers 200, then runs `pnpm add -D --save-exact`. The step holds no
 token. It hands the `pr` job the server, whether the pin moved, and the SHA-256 of
 `package.json` and `pnpm-lock.yaml` as it built with them.
@@ -237,7 +237,7 @@ refresh, comments on the issue `Automation needs a look`, or opens it assigned t
 [When automation needs a look](RELEASING.md#when-automation-needs-a-look) says what to do.
 
 - A tripped gate, a failing test, a guard that cannot read an index, an unreadable registry, a
-  dispatch that names no `x.y.z` version, a server npm does not serve within 15 minutes, a
+  dispatch that names no `x.y.z` version, a server npm does not serve within 45 minutes, a
   build job output or a recomputed pin the `pr` job does not accept, or a `version` on `main`
   that npm does not list yet each end the run red before anything is pushed. A pull request closed without merging, merged at another commit, left with auto-merge
   off, or not merged within 60 minutes ends it red after the push.

docs/RELEASING.md

@@ -213,9 +213,9 @@ dropped. Each comment links the run and says what happened:
 
 | The comment says | What to do |
 |---|---|
-| `The build job did not succeed.` and its result | `cancelled` means the job hit its 60 minute bound, most often a slow wiki, or someone cancelled the run. Run drift again. For `failure`, open the run and read the red step. A tripped gate in `pnpm build-index`, a failing `pnpm test`, a wiki the build could not read, or `The guard could not compare the indexes.` each end it there, before anything is pushed. Fix the cause, or run drift again once the wiki is back. |
+| `The build job did not succeed.` and its result | `cancelled` means the job hit its 90 minute bound, most often a slow wiki, or someone cancelled the run. Run drift again. For `failure`, open the run and read the red step. A tripped gate in `pnpm build-index`, a failing `pnpm test`, a wiki the build could not read, or `The guard could not compare the indexes.` each end it there, before anything is pushed. Fix the cause, or run drift again once the wiki is back. |
 | `The pr job did not succeed.` and its result | `cancelled` means the job hit its 75 minute bound or someone cancelled the run. Auto-merge stays on, so check the drift pull request. For `failure`, open the run and read the red step. `npm does not list X.Y.Z from package.json yet` means the release of the version on `main` is still running or failed, so follow [When a release run fails](#when-a-release-run-fails) and run drift again once npm has it. `was closed without merging` means someone closed the pull request. `merged <commit>, not <commit>` means the pull request merged a commit other than the one this run pushed, so read `git log` on `main` for what landed. `is off. Merge it, or turn auto-merge on again, by hand` means someone or something turned auto-merge off during the wait: merge the pull request with Rebase and merge once its checks pass, or turn auto-merge on again with `gh pr merge <number> --auto --rebase`, and the merge publishes. `failed 3 times in a row` means `gh` could not read the pull request, so check it by hand. `has not merged 3600 seconds after auto-merge was on` means its checks failed or are still running: auto-merge stays on, so it merges by itself once they pass, for example after you re-run a check that failed for a reason outside the repository. A red `Get a token of the tibia-sh App` step, or `Bad credentials` from `gh`, means the App's key or its installation no longer works, as [The tibia-sh App](#the-tibia-sh-app) describes. |
-| `The build job did not succeed.`, with `npm did not serve server X.Y.Z within 900 seconds.` in `Pin the server` | The run was moving the pin to server X.Y.Z, and for 15 minutes npm either did not list that version's tarball or a `HEAD` on it did not answer 200. Nothing was built or pushed. Check the server's release run in tibiawiki-mcp and `npm view @tibia.sh/tibiawiki-mcp@X.Y.Z dist.tarball`. Once npm serves it, run drift again by hand. A scheduled run also picks it up when it is `latest`. |
+| `The build job did not succeed.`, with `npm did not serve server X.Y.Z within 2700 seconds.` in `Pin the server` | The run was moving the pin to server X.Y.Z, and for 45 minutes npm either did not list that version's tarball or a `HEAD` on it did not answer 200. Nothing was built or pushed. Check the server's release run in tibiawiki-mcp and `npm view @tibia.sh/tibiawiki-mcp@X.Y.Z dist.tarball`. Once npm serves it, run drift again by hand. A scheduled run also picks it up when it is `latest`. |
 | `The build job did not succeed.`, with `The server-release dispatch asks for '…', not an x.y.z version.` in `Pin the server` | A `server-release` dispatch carried a payload version that is not `x.y.z`, and the step used none of it. Nothing was built or pushed. Fix the sender, tibiawiki-mcp's release workflow. Then run drift by hand, which moves the pin to npm's `latest`. |
 | `The pr job did not succeed.`, with a red `Check the build job's outputs` step | The build job handed on a value the `pr` job refuses: `changed`, `pin_moved` or `level` out of range, `Not a server version`, `moved the pin from A to B, which is not above it`, `kept the pin at B, but main pins A`, or `Neither the content nor the pin changed`. Nothing was pushed, and no token was minted. The build job runs the generator, so a value like this means either a mistake in `drift.yml`, such as a misspelt output, or a build job something tampered with. Read the build job's log, and in particular `Pin the server`. Run drift again only once you know which it was. |
 | `The pr job did not succeed.`, with `The recompute changed other files than package.json and pnpm-lock.yaml:` or `package.json changed in more than the pin of @tibia.sh/tibiawiki-mcp` in `Keep the recompute to the pin` | The `pr` job's own `pnpm add --lockfile-only` changed more than the server's pin. Nothing was pushed. That usually means a pnpm or `pnpm-workspace.yaml` change rewrote the manifests. Run the same command, `pnpm add -D --save-exact --lockfile-only --ignore-scripts --ignore-pnpmfile @tibia.sh/tibiawiki-mcp@X.Y.Z`, on a clean checkout of `main` and read `git diff`. When the extra change is right, land it in a reviewed pull request of its own, then run drift again. |

test/drift-workflow.test.ts

@@ -366,9 +366,9 @@ test('drift runs take turns in their own concurrency group, and none is cancelle
   assert.match(concurrency, /^ *cancel-in-progress: *false$/m, 'cancel-in-progress is not false');
 });
 
-test('the build job is bounded in time', () => {
+test('the build job is bounded at 90 minutes, room for the 45 minute wait for npm and the build', () => {
   // A wiki API that keeps answering 429 with a long Retry-After must end the run, red.
-  assert.match(scalar(buildJob(), 'timeout-minutes') ?? '', /^[1-9]\d*$/, 'the build job has no timeout-minutes');
+  assert.equal(scalar(buildJob(), 'timeout-minutes'), '90');
 });
 
 test('every action in the drift workflow is pinned to a full commit SHA, with its version beside it', () => {
@@ -1222,7 +1222,8 @@ type PinScenario = {
   listed?: string[];
   heads?: string[];
   pins?: boolean;
-  env?: Record<string, string>;
+  /** An undefined value leaves that variable unset, so the step falls back to its default. */
+  env?: NodeJS.ProcessEnv;
 };
 
 /** Runs the build job's pin step in a checkout that pins `pin`, against a stand-in npm, curl and pnpm. */
@@ -1284,6 +1285,12 @@ test('on its schedule, the pin step moves the pin to the latest server once npm
   ]);
 });
 
+test('the pin step waits up to 2700 seconds for npm unless told otherwise', () => {
+  const run = runPin({ latest: '0.14.1\n', listed: [`${tarballOf('0.14.1')}\n`], env: { DEADLINE_SECONDS: undefined } });
+  assert.equal(run.status, 0, run.log);
+  assert.match(run.log, /^Waiting up to 2700 seconds for npm to serve server 0\.14\.1\.$/m, 'the default deadline is not 2700 seconds');
+});
+
 test('on a server-release dispatch, the pin step waits for npm to list the version and serve its tarball, then pins it', () => {
   // npm does not know the version at first, then lists it before its tarball answers.
   const run = runPin({ event: 'repository_dispatch', requested: '0.15.0', latest: '0.14.1\n', listed: ['E404', '', `${tarballOf('0.15.0')}\n`], heads: ['404', '200'] });