ci: `pip-release` wheel jobs intermittently fail with `self-signed certificate` in `maturin-action`'s versions-manifest lookup

[phil-opp]

ci: pip-release wheel jobs intermittently fail with self-signed certificate while maturin-action downloads maturin, ejecting PRs from the merge queue

Summary

Wheel-build jobs in pip-release.yml intermittently fail with a Node.js TLS
error before any build work happens:

Error: self-signed certificate; if the root CA is installed locally,
try running Node.js with --use-system-ca
##[error]self-signed certificate; ...

It occurs while maturin-action downloads the maturin release asset. No compile
error, no test failure — the job dies during setup.

Because pip-release all green is a required merge-queue status
(.trunk/trunk.yaml), any batch containing an affected job is ejected and has to
be re-submitted. That is a real throughput cost while working through the v1.0
blocker set.

Occurrences (2026-08-11)

Time (UTC)	Batch	Job(s)
—	trunk-merge/pr-2859	linux (ubuntu-22.04, x86, binaries/cli, dora-rs-cli)
—	trunk-merge/pr-3039	macos (macos-15, aarch64, binaries/cli, dora-rs-cli)
18:19	trunk-merge/pr-3123	musllinux (ubuntu-22.04, aarch64, …) and windows (windows-latest, x64, …)
17:43	main	musllinux (ubuntu-22.04, x86, binaries/cli, dora-rs-cli) (run 31518988305)
21:53	trunk-merge/pr-3123	musleabi (armv7-unknown-linux-musleabihf, …, binaries/cli, dora-rs-cli) (run 31539935556)

The pr-3123 pair failed at the same second (18:19:50) on two different
runner OSes, which points at a network/registry event rather than anything
runner-local or PR-specific.

Three of the affected PRs are unrelated to packaging (#2859 is a dora node info
rendering fix; #3039 bounds a Python-side set), so the failures are clearly not
caused by the code under test.

Not the buildjet thing

The cache-provider buildjet is not valid annotation that appeared alongside the
first occurrence is a separate, non-fatal issue — the action swallows it and
the job continues (see #3125, which removed the step). This issue is only about
the TLS failure, which does abort the job.

Which request actually fails

Not the maturin download. In all five occurrences the last line before the error
is the pyproject lookup, and the line successful jobs print next —
Found maturin release from manifest: v1.14.1 — never appears. The failing
request is maturin-action's versions-manifest lookup:
findReleaseFromManifest → tc.getManifestFromRepo('PyO3', 'maturin', …),
i.e. an api.github.com / raw.githubusercontent.com fetch used only to turn
maturin>=0.13.2 into a concrete version. It has no retry around it.

Mitigation

Setting the action's maturin-version input makes it short-circuit
findVersion and skip the lookup entirely. Pinned to v1.14.1 (what the
manifest resolves to today, so no version change) on all 7 maturin-action
steps in pip-release.yml and both in release.yml.

Residual risk: the release download that follows is still a single unretried
fetch and could hit the same TLS event. DEPTH_ZERO_SELF_SIGNED_CERT from a
GitHub-hosted runner reaching a public host points at transient TLS
interception upstream rather than anything repo-side, so the pin is a surface
reduction, not a proof against recurrence — reopen with new occurrences if the
download step starts failing the same way.

Related

• ci(pip-release): drop the removed buildjet cache provider #3125 — removed the (unrelated, non-fatal) buildjet cache provider.
• .trunk/trunk.yaml — pip-release all green as a required status, which is
  why this ejects PRs rather than just being noisy.

---

Filed from an automated repo watch on 2026-08-11 after the third occurrence.