Frontier compute nodes have no internet, and the build runs inside a SLURM job. The venv is fetched on the login node first (Fetch Dependencies, --deps-only) so the compute-node build never has to reach PyPI. The retry path breaks that contract.
.github/scripts/retry-build.sh reacts to a failed first attempt with rm -rf build, which deletes build/venv. Attempt 2 then runs ./mfc.sh ... on the compute node, sees no venv, and tries to uv install from PyPI, which cannot succeed there:
+ echo ' Build failed — nuking build directory before retry...'
+ rm -rf build
+ ./mfc.sh test -v --dry-run -a -j 8 --gpu acc
mfc: OK > Created a Python virtual environment (venv).
mfc: (venv) Using uv for fast installation...
├─▶ Failed to fetch: `https://pypi.org/simple/hatchling/`
├─▶ error sending request for url (https://pypi.org/simple/hatchling/)
mfc: ERROR > (venv) Installation failed.
+ bash .github/scripts/classify-build-failure.sh build-build-gpu-acc.log frontier
classify-build-failure.sh matches that Failed to fetch ... pypi line and records a cluster-wide outage (ci-outage.sh mark frontier "PyPI/uv dependency install failed during build"). For the next 20 minutes every Frontier job on every PR exits 78 without submitting anything, and each of them re-reads the marker rather than the code.
Consequences seen today (2026-09-03):
Two fixes, either is enough:
retry-build.sh: keep build/venv when nuking (remove build/staging, build/install, and the CMake cache instead), so attempt 2 never needs PyPI. On Frontier the venv was fetched on the login node and is still valid.
classify-build-failure.sh: only mark an outage when the PyPI failure happened on attempt 1 (or on a login node). A fetch failure on a compute node is expected and says nothing about the cluster.
Not related to the code under test; MFC itself is unchanged by the retry.
Frontier compute nodes have no internet, and the build runs inside a SLURM job. The venv is fetched on the login node first (
Fetch Dependencies,--deps-only) so the compute-node build never has to reach PyPI. The retry path breaks that contract..github/scripts/retry-build.shreacts to a failed first attempt withrm -rf build, which deletesbuild/venv. Attempt 2 then runs./mfc.sh ...on the compute node, sees no venv, and tries touvinstall from PyPI, which cannot succeed there:classify-build-failure.shmatches thatFailed to fetch ... pypiline and records a cluster-wide outage (ci-outage.sh mark frontier "PyPI/uv dependency install failed during build"). For the next 20 minutes every Frontier job on every PR exits 78 without submitting anything, and each of them re-reads the marker rather than the code.Consequences seen today (2026-09-03):
Two fixes, either is enough:
retry-build.sh: keepbuild/venvwhen nuking (removebuild/staging,build/install, and the CMake cache instead), so attempt 2 never needs PyPI. On Frontier the venv was fetched on the login node and is still valid.classify-build-failure.sh: only mark an outage when the PyPI failure happened on attempt 1 (or on a login node). A fetch failure on a compute node is expected and says nothing about the cluster.Not related to the code under test; MFC itself is unchanged by the retry.