ci: stop a TestPyPI outage from costing the release its wheels

[JarryShaw]

1.5.0b2 reached PyPI with all 8 files, but its GitHub Release is missing three wheels — cp312, pp310 and pp311. The upload was never the problem; the step ordering was.

What actually happened

The pypi job runs three steps in this order: Publish to PyPI, then Publish package to TestPyPI, then Upload package to GitHub Release. On the Python 3.12 leg of run 35412937138, the per-step outcomes were:

[Publish to PyPI]             outcome=success
[Publish package to TestPyPI] outcome=failure

with:

TimeoutError: _ssl.c:1015: The handshake operation timed out
urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='test.pypi.org', port=443):
    Read timed out. (read timeout=5)

PyPI had already accepted the upload. A transient timeout against a secondary index then failed the job, and because Upload package to GitHub Release comes after it, that step never ran — the log contains zero lines for it. The 3.12 wheel went to PyPI and was never attached to the release.

The matrix has no fail-fast: false, so the same failure cancelled the pypy3.10 and pypy3.11 legs, which lost their wheels the same way.

Measured asset counts:

release	assets	wheels present
v1.5.0a1 (clean)	23	cp310, cp311, cp312, cp313, cp314, pp310, pp311
v1.5.0b2	10	cp310, cp311, cp313, cp314 — cp312, pp310, pp311 missing

(v1.5.0a1 also carries three conda build numbers per Python where b1/b2 carry one; that difference is unrelated to this failure and is not attributed to it. The attributable loss is exactly the three wheels.)

The fix

• continue-on-error: true on the TestPyPI step. It is a secondary target. Its availability must not gate the real release, and it certainly must not prevent the primary artefacts being attached.
• fail-fast: false on the pypi matrix. Each leg has its own wheel to attach; a cancelled leg never attaches it. One leg's bad luck should not cost three wheels.

A hypothesis this refutes, recorded because it was mine

My first reading was a duplicate-upload race — every leg building the same universal wheel, the first winning and the losers rejected as already existing. That was wrong, and the fix it implied was already in place: skip-existing: true is set on both publish steps (create-release.yml:234 and :242). The failing step was TestPyPI, not PyPI, and the cause was a network timeout. The log settled it; the wheel-size coincidence that suggested the race (every wheel is 1,279,537 bytes, because they are the same universal wheel) was real but explained nothing about the failure.

Verification

Re-parsed the workflow and asserted both changes landed where intended, with the neighbouring steps untouched:

pypi.strategy.fail-fast: False
pypi matrix legs: 7
step 'Publish to PyPI':                continue-on-error=False
step 'Publish package to TestPyPI':    continue-on-error=True
step 'Upload package to GitHub Release': continue-on-error=False
step order tail: ['Publish to PyPI', 'Publish package to TestPyPI', 'Upload package to GitHub Release']

What this does not do

It does not backfill the three wheels already absent from the v1.5.0b2 release, and it does not touch that release or its tag — those are published artefacts and the maintainer's call. PyPI is unaffected either way: pip install --pre pypcapkit gets the complete set, since all 8 files are there.

It also changes nothing about how the release is triggered or gated.