You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tools, makefile, .github/workflows: extract only the shard's EEST fixture set (erigontech#21771)
## Problem
`eest-spec-enginextests-benchmark-30m-parallel` failed on erigontech#21764 with
the Go linker dying mid-build
([run](https://github.com/erigontech/erigon/actions/runs/27421370747/job/81047607869)):
```
link: mapping output file failed: no space left on device
```
GitHub's `ubuntu-24.04` hosted pool currently serves two disk flavors —
72G and 145G root volumes. The same shard on the same branch passed 45
minutes earlier on a 145G runner (110G free after cleanup) and failed on
a 72G one (36G free after cleanup).
The job's disk demand sits right at that 36G line because every
`eest-spec-*` shard provisions **all three** EEST corpora through the
blanket `test-fixtures-eest` Make target, while
`tools/run-eest-spec-test.sh` only ever reads one of them:
| corpus | tarball | extracted |
|---|---|---|
| eest_benchmark | 1.0G | 5.3G |
| eest_devnet | 0.6G | 10G |
| eest_stable | 0.4G | 8.1G |
36G free − ~8G (Go toolchain + mod/build cache restore) − 2G tarballs −
23.4G extraction ≈ 2.6G left when `go build` starts → ENOSPC at link.
The ±1-2G run-to-run variance is why it flakes instead of failing
deterministically.
## Fix
- Move fixture provisioning into `tools/run-eest-spec-test.sh`, which
already resolves the shard's corpus from its name — each shard now
downloads/extracts only the set it reads. Worst-case footprint drops
from ~35G to ~22G (devnet shards), ~17G for the benchmark shard that
flaked.
- The zkevm/non-zkevm Makefile rule split existed solely to pick the
fixture prerequisite, so the four pattern rules collapse to two
(race/non-race).
- Add `--download-only` to `tools/test-fixtures.sh` and use it in
`cache-warming-eest-fixtures.yml`. The warmer caches only the `.tar.gz`
files but was extracting all four corpora (~27G) — on a runner that
doesn't even run the cleanup-space step, i.e. the same ENOSPC waiting to
happen on a 72G runner whenever the probe misses.
Local `make eest-spec-*` behaviour is unchanged: provisioning is a
sentinel-guarded no-op when the corpus is already extracted, and `make
test-fixtures-eest`/`test-fixtures-zkevm` remain for prefetching
everything.
## Verification
TDD note: infra/shell change with no Go behaviour; verified functionally
instead of via Go tests:
- Synthetic end-to-end test of `test-fixtures.sh` (tiny `file://`
manifest in a temp dir): download-only cold / idempotent re-run /
normal-mode extract from existing tarball / sentinel no-op /
download-only re-download after tarball deletion — all pass.
- `make -n` for one shard per class (plain, race, zkevm-race,
benchmark): correct binary (`evm` vs `evm.race`), no blanket fixture
extraction in any recipe.
- Smoke run of `run-eest-spec-test.sh statetests-stable` against a
populated cache: in-script provisioning hits the cached fast-path and
proceeds into the run stage.
- `actionlint` on both workflows; `shellcheck` adds no new findings;
`make lint` clean twice.
0 commit comments