Deploy container is node 20, which caps wrangler at 4.86.0 #21

Новая задача

2026-08-09T05:04:45+02:00

clawbot прокомментировал(а)

2026-08-09 05:04:45 +02:00

Соавтор

Split out of #7.

The coupling

.gitea/workflows/deploy.yml's deploy job runs on a pinned node:20 digest
(node 20.20.2) and installs wrangler@4.86.0. Those two pins are load-bearing
on each other: wrangler dropped node 20 support after 4.86.0.

Measured in the pinned image:

$ docker run --rm node@sha256:8f693eaa... sh -c \
    'npm install -g wrangler@4.120.0; wrangler --version'
install exit=0                      # EBADENGINE is only a warning
Wrangler requires at least Node.js v22.0.0. You are using v20.20.2.
version exit=1

$ curl -s https://registry.npmjs.org/wrangler/4.120.0 | jq .engines
{"node": "&gt;=22.0.0"}
$ curl -s https://registry.npmjs.org/wrangler/4.86.0  | jq .engines
{"node": "&gt;=20.3.0"}

Worth recording because it is easy to get wrong: before #7 the step was an
unpinned npm install -g wrangler, and that was not installing latest.
npm resolves a bare name to the newest version whose engines the running node
satisfies, so on node 20 it resolved to 4.86.0. Pinning "the latest version"
therefore silently changed the deployed tool onto a node it cannot run on, and
because npm install only warns about engines, the failure surfaces one step
later at the actual deploy. #7 pins 4.86.0 precisely because that is what has
been running.

Why to change it

Staying on node 20 means the wrangler pin can never move forward, and node 20
itself reaches end of life. The pinned pair works today and is not urgent, but
it is a dead end.

Done when

The deploy job's container is a pinned node 22 (or later LTS) digest.
wrangler is pinned to a version whose engines.node that image satisfies.
Both are proven together before merge, not after: temporary branch trigger on
on.push.branches, if: github.ref_name == 'main' kept on the deploy job so
Cloudflare is untouched, and a probe job that installs wrangler in the new
image and runs wrangler --version and wrangler pages deploy --help.
The main deploy run is watched afterwards and the live site confirmed.

Split out of #7. ## The coupling `.gitea/workflows/deploy.yml`'s `deploy` job runs on a pinned `node:20` digest (node 20.20.2) and installs `wrangler@4.86.0`. Those two pins are load-bearing on each other: wrangler dropped node 20 support after 4.86.0. Measured in the pinned image: ``` $ docker run --rm node@sha256:8f693eaa... sh -c \ 'npm install -g wrangler@4.120.0; wrangler --version' install exit=0 # EBADENGINE is only a warning Wrangler requires at least Node.js v22.0.0. You are using v20.20.2. version exit=1 ``` ``` $ curl -s https://registry.npmjs.org/wrangler/4.120.0 | jq .engines {"node": ">=22.0.0"} $ curl -s https://registry.npmjs.org/wrangler/4.86.0 | jq .engines {"node": ">=20.3.0"} ``` Worth recording because it is easy to get wrong: before #7 the step was an unpinned `npm install -g wrangler`, and that was **not** installing `latest`. npm resolves a bare name to the newest version whose `engines` the running node satisfies, so on node 20 it resolved to 4.86.0. Pinning "the latest version" therefore silently changed the deployed tool onto a node it cannot run on, and because `npm install` only warns about `engines`, the failure surfaces one step later at the actual deploy. #7 pins 4.86.0 precisely because that is what has been running. ## Why to change it Staying on node 20 means the wrangler pin can never move forward, and node 20 itself reaches end of life. The pinned pair works today and is not urgent, but it is a dead end. ## Done when - The `deploy` job's container is a pinned node 22 (or later LTS) digest. - `wrangler` is pinned to a version whose `engines.node` that image satisfies. - Both are proven together before merge, not after: temporary branch trigger on `on.push.branches`, `if: github.ref_name == 'main'` kept on the deploy job so Cloudflare is untouched, and a probe job that installs wrangler in the new image and runs `wrangler --version` and `wrangler pages deploy --help`. - The `main` deploy run is watched afterwards and the live site confirmed.

clawbot ссылка на эту проблему

2026-08-09 05:09:18 +02:00

Hash-pin every external reference in deploy.yml, verified on a real runner (closes #7) #22

clawbot ссылка на эту проблему

2026-08-09 05:09:50 +02:00

Hash-pin every external reference in deploy.yml, verified on a real runner (closes #7) #22

clawbot ссылка на эту проблему

2026-08-09 05:10:09 +02:00

Hash-pin every external reference in .gitea/workflows/deploy.yml #7

clawbot ссылка на эту проблему

2026-08-09 05:11:32 +02:00

Hash-pin every external reference in .gitea/workflows/deploy.yml #7