CI: every job downloads a CPython interpreter, and that download is a recurring single point of failure

template/.github/workflows/tests.yml.jinja、nightly.yml.jinja、commit-message.yml.jinja から始め、次に .github/workflows にある対応するファイルと比較します。一覧にある uv python install の各出現箇所を確認し、Python の完全なマトリクスを、提案されている runner 提供のインタープリターと照合します。完了とは、ワークフローの同等性が維持され、これらのジョブで CPython のダウンロードに依存しなくなることを意味します。

What happens

Every CI job in the template, and therefore in all seven generated projects, begins with a step that downloads a CPython interpreter:

- name: Set up Python
  run: uv python install ${{ matrix.python-version }}

uv python install fetches a build from the astral-sh/python-build-standalone GitHub release. When that download fails, the job dies before running a single test, and the PR goes red for a reason unrelated to its contents.

Over roughly twelve hours on 2026-08-12/13 this failed repeatedly, on main and on four separate pull requests, always at the same step:

error: Failed to install cpython-3.12.12-linux-x86_64-gnu
  Caused by: Request failed after 3 retries
  Caused by: Failed to download https://github.com/astral-sh/python-build-standalone/releases/download/.../cpython-3.12.12+...-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz
  Caused by: http2 error
  Caused by: stream error received: refused stream before processing any application logic

It also appeared as 503 Service Unavailable and curl: (56) Connection died. It hit ubuntu, macOS and Windows runners, and every Python version in the matrix. uv already retries three times internally, and that was not enough.

The same outage took out other GitHub release downloads in the same window (the gitleaks install step, and Read the Docs' asdf install uv), so the cause is upstream rather than anything in this repo. The point of this issue is that our workflows put that download on the critical path when they do not have to.

Why it is worth fixing rather than re-running

• It is not rare. Five re-runs in one session, and each costs a full matrix.
• It is indistinguishable at a glance from a real failure. Every occurrence needs someone to open the job log and read which step died before they know whether to trust the red.
• It scales with the fleet: ten uv python install steps in the template's tests.yml alone, times eight repositories.
• The runner images already ship the interpreters we ask for. actions/setup-python resolves common versions from the runner's tool cache with no network download at all.

Affected files

template/.github/workflows/:

• tests.yml.jinja — 8 occurrences (lines 56, 91, 136, 193, 223, 252, 325, 358)
• nightly.yml.jinja — 1 (line 44)
• commit-message.yml.jinja — 1 (line 52)

and the same shape in this repository's own .github/workflows/{tests,nightly,commit-message}.yml, which must be kept in parity.

Options

1. actions/setup-python for the interpreter, uv for everything else. Replace the uv python install step with actions/setup-python, and set UV_PYTHON_PREFERENCE=only-system so uv uses it rather than fetching its own. Versions present in the runner tool cache then need no download.
2. Keep uv python install and add a retry wrapper. Smaller change, but it makes a bad minute into a slow minute rather than removing the dependency, and uv already retries three times.
3. Do nothing and re-run. The status quo. Worth stating explicitly, because the cost is real but bounded.

Option 1 is the one that removes the failure mode. It also needs care: setup-python and uv python install do not resolve versions identically (patch pinning, free-threaded builds, and versions newer than the runner image differ), so this should be measured on the full matrix before it fans out.

Not in scope

The astral-sh/setup-uv step that installs uv itself, and the pinned # renovate: versions on it. Those are a separate download and have not been the failing step.