ci: stop contacting live registries in publish dry-runs

[scarmuega]

publish-node and publish-haskell fail on every pull request. They are the only two publish jobs whose dry-run mode contacts a live package registry; rust, python, go and dotnet validate locally and pass.

This is independent of #209 and #210 — it reproduces on #210, which contains nothing but a one-line workflow permissions change.

node

npm publish --dry-run still asks the registry whether the version exists:

npm error You cannot publish over the previously published versions: 0.19.2.

The version in gen/node/package.json only changes at release time, so it matches what is already on npm for all but a brief window after each bump.

npm 10 never made that request. Verified directly:

$ npx npm@10 publish --dry-run   # @utxorpc/spec 0.19.2
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access (dry-run)   → exit 0

$ npx npm@11 publish --dry-run   # identical package.json
npm error You cannot publish over the previously published versions: 0.19.2.  → exit 1

#204 moved this job from node-version: 20.11.0 to 24.5.0 for trusted publishing — npm 10.2.4 to npm 11.5.1. The command was never touched; its behaviour changed underneath it. Because that same PR also broke pr-check.yml at startup (#210), the job never ran on a pull request again and the regression stayed invisible.

npm pack --dry-run does the same packing and manifest validation without the registry round-trip.

haskell

stack upload --candidate is not a simulation — it pushes a real candidate release to Hackage from unreviewed pull request code. Beyond being wrong on its own terms, it fails:

Error: [S-2804] forbidden upload
       Usually means: you've already uploaded this package/version combination.
       Ignoring error and continuing.
       Package name and version already exist in the database
Error: [S-6108] unhandled status code: 404
       Upload failed on utxorpc-0.0.19.2-docs.tar.gz

Note stack ignores the rejected tarball upload. The fatal error is the second command, stack upload --candidate -d ., which posts haddocks to the candidate URL. Hackage currently has candidates only up to 0.0.18.1; there is none for any 0.0.19.x:

/package/utxorpc-0.0.18.1/candidate → 200
/package/utxorpc-0.0.19.0/candidate → 404
/package/utxorpc-0.0.19.2/candidate → 404

So the docs upload has no candidate to attach to and 404s. This job last passed on 2026-05-01 at 12:35 UTC; the cabal version moved to 0.0.19.0 at 16:17 UTC that day and Hackage published it at 16:30 UTC. The next pull request, 2026-05-05, failed on publish-haskell alone — and every one since.

The preceding steps already run stack test, stack sdist and stack haddock --haddock-for-hackage, which is every check a pull request needs, so the candidate upload is dropped rather than replaced.

Scope

Releases are untouched. Both real uploads live in the release branches of these actions:

• node: npm publish --access public under inputs.mode == 'release'
• haskell: stack upload --test-tarball . under inputs.mode == 'release' && startsWith(github.ref, 'refs/tags/v')

The only behaviour lost is the candidate upload that ran during release.yml's pre-flight dry-run stage, which the real upload immediately superseded.

Verifying

This PR is its own test — publish-node and publish-haskell should both go green, which no pull request has managed since 2026-05-01. Requires #210 to be on the branch or merged first, otherwise pr-check.yml never starts.

🤖 Generated with Claude Code