fix(ci): cache uv and raise its HTTP timeout, so PyPI egress stops flaking #1161

Merged

coilysiren merged 1 commit from fix/ci-uv-cache into main

2026-08-20 09:12:10 +00:00

coilyco-ops commented

2026-08-20 09:04:29 +00:00

Member

ci / aos-eval-tests and both gates have been flapping red with no code change behind it. Run 3629 green, 3631 red, 3632 green, all on unrelated commits, and PR #1156 caught a red purely by timing.

The job log names the cause exactly:

Failed to resolve requirements from `build-system.requires`
No solution found when resolving: `setuptools>=68.1.2`
Request failed after 3 retries in 45.3s
Failed to fetch: https://pypi.org/simple/setuptools/
operation timed out

Why it happens

Both local packages build through PEP 517 with a setuptools backend. A build requirement never lands in uv.lock, so uv resolves setuptools>=68.1.2 from PyPI in an isolated build env on every cold cache, and every CI container starts cold. The runner's egress to PyPI is intermittent, so the job passes or fails on whether that single fetch lands.

Both lockfiles are already committed, so this is not a resolution gap. It is one unlockable fetch on a flaky path.

Shape

The three jobs that run uv now cache ~/.cache/uv, keyed on both lockfiles, beside the pre-commit cache they already keep. A warm cache never reaches the network for the build backend at all.
UV_HTTP_TIMEOUT: "180" lifts uv's 30s default for the cold-cache case that still must fetch.

Coverage is symmetric across ci.yml aos-eval-tests, ci.yml gate, and promote.yml gate. The cache steps use uses: rather than run:, so test_pull_request_ci_workflow.py still sees the two workflows in step, and that test passes.

`ci / aos-eval-tests` and both gates have been flapping red with no code change behind it. Run 3629 green, 3631 red, 3632 green, all on unrelated commits, and PR #1156 caught a red purely by timing. The job log names the cause exactly: ``` Failed to resolve requirements from `build-system.requires` No solution found when resolving: `setuptools>=68.1.2` Request failed after 3 retries in 45.3s Failed to fetch: https://pypi.org/simple/setuptools/ operation timed out ``` ## Why it happens Both local packages build through PEP 517 with a setuptools backend. A build requirement never lands in `uv.lock`, so uv resolves `setuptools>=68.1.2` from PyPI in an isolated build env on every cold cache, and every CI container starts cold. The runner's egress to PyPI is intermittent, so the job passes or fails on whether that single fetch lands. Both lockfiles are already committed, so this is not a resolution gap. It is one unlockable fetch on a flaky path. ## Shape * The three jobs that run uv now cache `~/.cache/uv`, keyed on both lockfiles, beside the pre-commit cache they already keep. A warm cache never reaches the network for the build backend at all. * `UV_HTTP_TIMEOUT: "180"` lifts uv's 30s default for the cold-cache case that still must fetch. Coverage is symmetric across `ci.yml` `aos-eval-tests`, `ci.yml` `gate`, and `promote.yml` `gate`. The cache steps use `uses:` rather than `run:`, so `test_pull_request_ci_workflow.py` still sees the two workflows in step, and that test passes.

coilyco-ops added 1 commit

2026-08-20 09:04:29 +00:00

fix(ci): cache uv and raise its HTTP timeout, so PyPI egress stops flaking

ci / aos-cli-tests (pull_request) Successful in 20s

Details

ci / aos-eval-tests (pull_request) Successful in 9s

Details

ci / ward-doctor (pull_request) Successful in 14s

Details

ci / gate (pull_request) Successful in 1m0s

Details

0091e44277

aos-eval-tests and both gates have been flapping red with no code change
behind it. The log names the cause exactly:

    Failed to resolve requirements from `build-system.requires`
    No solution found when resolving: `setuptools>=68.1.2`
    Request failed after 3 retries in 45.3s
    Failed to fetch: https://pypi.org/simple/setuptools/
    operation timed out

Both local packages build through PEP 517 with a setuptools backend. A
build requirement is not in uv.lock, so uv resolves it from PyPI in an
isolated build env on every cold cache, which every CI container is. The
runner's egress to PyPI is intermittent, so the job passes or fails on
whether that one fetch lands.

Nothing about it was specific to a change under review: run 3629 was
green, 3631 red, 3632 green, all on unrelated commits.

The jobs that run uv now cache ~/.cache/uv keyed on both lockfiles,
beside the pre-commit cache they already keep, so a warm cache never
reaches the network for the build backend at all. UV_HTTP_TIMEOUT lifts
uv's 30s default for the cold-cache case that still must.

Coverage is symmetric across ci.yml aos-eval-tests, ci.yml gate, and
promote.yml gate. The cache steps use `uses:` rather than `run:`, so the
promote/ci parity test still sees the two workflows in step.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-20 09:04:29 +00:00

coilysiren merged commit f790fd2ad9 into main

2026-08-20 09:12:10 +00:00

coilysiren deleted branch fix/ci-uv-cache

2026-08-20 09:12:11 +00:00

coilysiren referenced this pull request from a commit

2026-08-20 09:12:11 +00:00

fix(ci): cache uv and raise its HTTP timeout, so PyPI egress stops flaking (#1161)