Files
OmniRoute/.github/workflows
Diego Rodrigues de Sa e Souza e6523da2a1 fix(ci): unblock the npm publish — dynamic runner + reuse CI's next-build (#8941)
The v3.8.49 publish failed: `Build CLI bundle` runs `npm run build:cli`, which shells
out to a full `next build` when `.build/next/standalone/server.js` is missing. That
build's working set outgrew the 16 GB GitHub-hosted runner during this cycle, so the
job died at 6m20s with

    Creating an optimized production build ...
    ##[error]The runner has received a shutdown signal.

and every step after it — artifact validation, SBOM, tarball boot-smoke, the staged
publish — was skipped. The same job had passed in 16 minutes for v3.8.48, so this is
the build growing past the runner, not the runner degrading. ci.yml already routes its
heavy jobs around this via the USE_VPS_RUNNER expression; npm-publish.yml had
`runs-on: ubuntu-latest` hardcoded and no way out.

Two changes, one for the fast path and one for the fallback:

- `runs-on` now uses the SAME expression as ci.yml's build/test-unit, so the operator
  can send the publish to the 32-core self-hosted runner. Kept verbatim (including the
  fork-safety clause that is always true here, since this workflow never runs on
  pull_request) so the expression stays greppable across workflows.
- A best-effort step restores the `next-build` artifact that CI already produced for
  the SAME commit, matching on `head_sha` — same commit, same tree, so no equality gate
  is needed beyond the match itself. `build:cli` then finds the standalone tree and
  skips the build entirely, turning the heaviest step into a download. Retention is one
  day, so every miss (no successful CI run, expired artifact, bad extract) logs a notice
  and falls through to the build — which is exactly why the dynamic runner above is the
  necessary backstop rather than a nice-to-have.

Needs `actions: read` to look up the run and download the artifact. All inputs reach the
script through `env:`, never interpolated into the shell body. No new zizmor findings:
the step uses the `gh` CLI rather than a new `uses:`, so the unpinned-uses count is
unchanged (189 measured locally == the devbox side of the 190 baseline).

Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
2026-07-29 22:17:15 -03:00
..
2026-06-20 07:09:43 -03:00
2026-07-29 15:18:55 -03:00
2026-06-20 07:09:43 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-06-06 19:13:11 -03:00
2026-06-29 08:40:06 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00
2026-07-29 15:18:55 -03:00