Repository navigation
fix(ci): keep the next-build artefact on disk, not on the runner's tmpfs - #11896
Merged
Merged
Conversation
Contributor
CI Coverage Report
Coverage artifact was not available for this run. |
On the .113 pool /tmp is a 12 GB tmpfs — it is RAM. The 1.3 GB next-build
artefact was parked there four times over: the Build job tar'd it to
/tmp/e2e-build.tar.gz (6 min), three E2E jobs downloaded it to /tmp/ and
extracted from there, and npm-publish.yml pulled it with gh run download into
/tmp/next-build. Measured on the v3.8.50 publish runs: that download step took
27 min (9th attempt) and 32 min (10th) — 42% of a 76-minute job — while the
very same bytes upload from disk in 2 min and the box pulls from GitHub at
7.3 MB/s (1.3 GB ≈ 3 min). Network was never the bottleneck; a tmpfs at 75%
under memory pressure was.
Every site now uses $RUNNER_TEMP / ${{ runner.temp }}: per-runner, on disk
(_work/_temp under the runner dir on the pool, /home/runner/work/_temp on
hosted images), and cleaned by the runner between jobs.
It also removes a latent race: e2e-build.tar.gz is a FIXED name under a /tmp
shared by every runner on the box, so two E2E shards on different runners could
overwrite each other's download mid-extraction. RUNNER_TEMP is per runner.
The supply-chain guard in tests/unit/npm-publish-artifact-provenance.test.ts
pins the candidate-run selection and the --name, not the directory; it stays
green. check:workflows --ratchet: zizmor unchanged at the baseline.
… (pwsh has no $RUNNER_TEMP) The Electron Package Smoke matrix runs on windows-latest, whose default shell is pwsh: $RUNNER_TEMP is empty there (pwsh spells it $env:RUNNER_TEMP), so the first cut's tar -xzf "$RUNNER_TEMP/e2e-build.tar.gz" tried to open '/e2e-build.tar.gz' and failed. A path relative to the workspace works in bash and pwsh alike, and hosted workspaces are ephemeral. The producer (Build, Linux, bash) and npm-publish keep $RUNNER_TEMP.
diegosouzapw
force-pushed
the
fix/ci-artifact-download-to-disk
branch
from
August 28, 2026 18:47
5235459 to
35d5d25
Compare
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…pfs (cheaper-inference#11896) * fix(ci): keep the next-build artefact on disk, not on the runner's tmpfs On the .113 pool /tmp is a 12 GB tmpfs — it is RAM. The 1.3 GB next-build artefact was parked there four times over: the Build job tar'd it to /tmp/e2e-build.tar.gz (6 min), three E2E jobs downloaded it to /tmp/ and extracted from there, and npm-publish.yml pulled it with gh run download into /tmp/next-build. Measured on the v3.8.50 publish runs: that download step took 27 min (9th attempt) and 32 min (10th) — 42% of a 76-minute job — while the very same bytes upload from disk in 2 min and the box pulls from GitHub at 7.3 MB/s (1.3 GB ≈ 3 min). Network was never the bottleneck; a tmpfs at 75% under memory pressure was. Every site now uses $RUNNER_TEMP / ${{ runner.temp }}: per-runner, on disk (_work/_temp under the runner dir on the pool, /home/runner/work/_temp on hosted images), and cleaned by the runner between jobs. It also removes a latent race: e2e-build.tar.gz is a FIXED name under a /tmp shared by every runner on the box, so two E2E shards on different runners could overwrite each other's download mid-extraction. RUNNER_TEMP is per runner. The supply-chain guard in tests/unit/npm-publish-artifact-provenance.test.ts pins the candidate-run selection and the --name, not the directory; it stays green. check:workflows --ratchet: zizmor unchanged at the baseline. * fix(ci): download the next-build artefact to a workspace-relative dir (pwsh has no $RUNNER_TEMP) The Electron Package Smoke matrix runs on windows-latest, whose default shell is pwsh: $RUNNER_TEMP is empty there (pwsh spells it $env:RUNNER_TEMP), so the first cut's tar -xzf "$RUNNER_TEMP/e2e-build.tar.gz" tried to open '/e2e-build.tar.gz' and failed. A path relative to the workspace works in bash and pwsh alike, and hosted workspaces are ephemeral. The producer (Build, Linux, bash) and npm-publish keep $RUNNER_TEMP.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
Na pool
.113,/tmpé um tmpfs de 12 GB — é RAM. O artefatonext-buildde 1,3 GB era estacionado lá quatro vezes: oBuildo comprimia em/tmp/e2e-build.tar.gz(6 min), três jobs E2E baixavam para/tmp/e extraíam dali, e onpm-publish.ymlpuxava comgh run downloadpara/tmp/next-build.Medido nas tentativas de publicação da v3.8.50: esse download levou 27 min (9ª) e 32 min (10ª) — 42% de um job de 76 minutos. Os mesmos bytes sobem do disco em 2 min, e a caixa baixa do GitHub a 7,3 MB/s (1,3 GB ≈ 3 min). A rede nunca foi o gargalo; um tmpfs a 75% sob pressão de memória era.
O que muda
Todos os pontos passam a usar
$RUNNER_TEMP/${{ runner.temp }}: por-runner, em disco (_work/_tempsob o diretório do runner na pool;/home/runner/work/_tempnas imagens hospedadas), e limpo pelo runner entre jobs.ci.ymlBuild)tar -czf /tmp/e2e-build.tar.gz+path: /tmp/e2e-build.tar.gz$RUNNER_TEMP/…+${{ runner.temp }}/…ci.ymlpath: /tmp/+tar -xzf /tmp/e2e-build.tar.gz${{ runner.temp }}+"$RUNNER_TEMP/e2e-build.tar.gz"npm-publish.ymlgh run download … --dir /tmp/next-build--dir "$RUNNER_TEMP/next-build"Race latente que isto também remove
e2e-build.tar.gzé um nome fixo num/tmpcompartilhado por todos os runners da caixa: dois shards E2E em runners diferentes podiam sobrescrever o download um do outro no meio da extração.RUNNER_TEMPé por runner.Validação
tests/unit/npm-publish-artifact-provenance.test.ts(guard de supply-chain do fast path) pina a seleção de run candidato e o--name, não o diretório — 3/3 verdescheck:workflows --ratchet: zizmor inalterado na baseline (194), YAML válido nos dois arquivosRefs #11877
⚠️ base-red inherited: #11866 (
Unit Tests (1/8)— allowlist da Alibaba, consertada em #11867)