mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-13 18:32:12 +03:00
dea6bb8b6b
* fix(ci): publish npm from a hosted runner so provenance is accepted The v3.8.50 staged publish failed at the upload: npm error code E422 npm error 422 Unprocessable Entity - POST https://registry.npmjs.org/-/stage/package/omniroute Error verifying sigstore provenance bundle: Unsupported GitHub Actions runner environment: "self-hosted". Only "github-hosted" runners are supported when publishing with provenance. 3.8.49 published fine on 2026-07-30 because it predates USE_VPS_RUNNER being turned on (2026-08-02). 3.8.50 is the first release since, so the incompatibility had been latent for four weeks with nothing to surface it. Neither obvious fix works on its own: - dropping --provenance would regress supply-chain posture; 3.8.49 carries a SLSA attestation and 3.8.50 must not ship without one; - moving the whole job to a hosted runner reintroduces the failure that made it self-hosted in the first place — 16 GB is not enough for build:cli's next-build fallback (documented on the job's runs-on). So the work is split by what each runner is actually needed for. The self-hosted job keeps every heavy gate — build, artifact validation, boot-smoke, the clean-install/upgrade proof — and then packs the tarball it just proved and hands it over. A new `stage-npm` job on ubuntu-latest downloads those exact bytes and performs the upload, which needs no memory at all. `npm pack --ignore-scripts` on the producing side and `--ignore-scripts` on the publishing side both matter: prepublishOnly is `build:cli-api && build:cli && check:pack-artifact`, and the job already runs all three as explicit steps (the dist/ prune is logged twice today — once at Build CLI bundle, once redundantly inside npm stage publish). Re-running them on the small hosted runner would rebuild bytes that were already built, validated and boot-smoked. The DIRECT emergency fallback moved too — it published with --provenance and would have hit the identical 422. * chore(quality): re-baseline zizmor for the new hosted publish job The `stage-npm` job adds 2 zizmor findings (192 -> 194), both of the same deliberate @vN convention every workflow in this repo already follows: unpinned-uses on actions/download-artifact@v8 and actions/setup-node@v7, plus the cache-poisoning that setup-node@v7 already raises on the two other jobs in this very file. SHA-pinning only the new job would break the convention. No new class: zero template-injection, artipacked, dangerous-triggers or excessive-permissions. The job declares contents:read + id-token:write, which is the minimum npm provenance needs.