fix(ci): cap heavy builds at two runners with the omni-build label - #11932
Merged
Merged
Conversation
The .113 box (31 GB) holds one next-build (14–16 GB RSS) comfortably and two at the edge; on 2026-08-28 the kernel killed main's build twice while PR builds ran beside it. Labels are the runner-side cap: only omniroute-113-5 and omniroute-113-6 carry omni-build (added through the runners API, no re-registration), and every job that runs a next build — ci.yml build, npm-publish.yml publish, both nightly-release-green validations — now asks for that label. A third heavy job queues on GitHub instead of racing for memory. The six other runners keep omni-release and no longer take builds. Pairs with the heavy-build-* concurrency lanes (#11901); documented in docs/ops/RUNNER_BOX.md.
Contributor
CI Coverage Report
Coverage artifact was not available for this run. |
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…iegosouzapw#11932) The .113 box (31 GB) holds one next-build (14–16 GB RSS) comfortably and two at the edge; on 2026-08-28 the kernel killed main's build twice while PR builds ran beside it. Labels are the runner-side cap: only omniroute-113-5 and omniroute-113-6 carry omni-build (added through the runners API, no re-registration), and every job that runs a next build — ci.yml build, npm-publish.yml publish, both nightly-release-green validations — now asks for that label. A third heavy job queues on GitHub instead of racing for memory. The six other runners keep omni-release and no longer take builds. Pairs with the heavy-build-* concurrency lanes (diegosouzapw#11901); documented in docs/ops/RUNNER_BOX.md.
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
1 participant
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.
Por quê
A
.113(31 GB) aguenta umnext-build(14–16 GB de RSS) com folga e dois no limite. Em 28/08 o kernel matou o build demainduas vezes com builds de PR ao lado. As faixas deconcurrencyda #11901 limitam por grupo no GitHub; o label é o teto do lado do runner.O que muda
omni-buildadicionado a dois runners via API (omniroute-113-5,omniroute-113-6) — sem re-registro, sem tocar na caixa; já aplicado.next buildpassa a pedir[self-hosted, omni-build]:ci.ymlbuild,npm-publish.ymlpublish, as duas validações donightly-release-green. Um 3º build enfileira no GitHub em vez de disputar memória.omni-releasee deixam de receber builds (hoje nenhum job leve usa a pool — shards rodam em runner hospedado).docs/ops/RUNNER_BOX.mddocumenta o teto por label e como ampliar (rotular outro runner, nunca além do que 31 GB aguenta).Validação
check:workflows --ratchet: zizmor na baseline (194), regra provenance × self-hosted 0scripts/vps/release-runner-up.shregistra runners comomni-release— intencionalmente não adicionaomni-build(o teto é por rotulagem explícita)Refs #11901