mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-15 19:52:50 +03:00
7bb3bc7e32
* fix(ci): pin Build (advisory) to a hosted runner with memory provisioning `Build (advisory)` has been reporting a permanent red on every PR while producing no usable signal at all. Measured over the last 25 quality.yml runs (2026-08-14): not one instance of the job reached a conclusion. Every sample was either queued on the self-hosted pool — 2 runners, omniroute-113-6/7, both permanently busy; one job sat queued for over 2 hours and was still unclaimed — or, when it did land on a runner, killed mid-build by this workflow's own cancel-in-progress concurrency. All 6 sampled "failures" are exit 143 / "The runner has received a shutdown signal" at ~3.5 min into `npm run build`. Zero OOM, zero build errors. The job was consuming a runner the real gates compete for while telling every PR author it was broken. Gap 19 deliberately left USE_VPS_RUNNER governing build-like jobs, on the premise that the build needs the .113's RAM. That premise no longer holds: `Fast Production Build` (build.yml) runs `build:release` — a superset of this job's `npm run build`, plus the CLI bundle — on plain ubuntu-latest and passed 24 of its last 25 runs in ~15 min. The difference is memory PROVISIONING, not the machine: a 10 GB swapfile plus a 12 GB V8 heap. Swap is the part that matters, because --max-old-space-size bounds only V8's JS heap and never Turbopack's native Rust allocation (#6409). Pins the job to ubuntu-latest and mirrors both settings from build.yml. USE_VPS_RUNNER keeps its other consumers (ci.yml Build, nightly-release-green, npm-publish), so the variable stays meaningful. Fork safety is strictly improved: no PR can reach the LAN runner through this job any more. check:workflows --ratchet: 186 zizmor findings, baseline 190, no regression. prettier + YAML parse: clean. * fix(ci): scope Build (advisory) to fork PRs Follow-up to the hosted-runner pin in this same PR, after measuring what the job is actually for. build.yml's `Fast Production Build` triggers on `push: branches: ["**"]` and runs `build:release` — a superset of this job's `npm run build`, plus the CLI bundle. For an own-origin branch that push fires here, so the tree was being built twice per PR. A fork contributor pushes to THEIR repo, so build.yml never runs in this repo and this job is their only pre-merge build signal. That could have argued for deleting the job, except the traffic says otherwise: 72 of the last 100 PRs into release/** come from forks. The fork case is the majority, not the exception. So the job earns its place — it just should not duplicate build.yml for the own-origin 28%. Added the fork filter to the existing `if`. Also corrects the reliability claim in the previous commit message. Over a wider window the job is not literally never-green: across 2026-08-13/14 it reached `success` on roughly 10-15% of runs (13/138 on 08-14, 7/53 sampled on 08-13). Chronically unreliable, not permanently dead — the conclusion and the fix are unchanged. The #7307 guard in tests/unit/build/check-workflows.test.ts pinned the old self-hosted expression, so it is realigned here: it now asserts the hosted pin, the absence of self-hosted/USE_VPS_RUNNER in the job's DIRECTIVES (the comment legitimately explains why the pool was abandoned, so the scan strips comments), both memory settings, and the fork filter. Mutation-validated — restoring self-hosted, dropping the swapfile, or flipping the fork filter each turns it red. check-workflows.test.ts: 32 pass, 0 fail. check:workflows --ratchet: 186 findings, baseline 190, no regression. --------- Co-authored-by: Xiangzhe <bakryun0718@proton.me>