|
| 1 | +# NPM release runners |
| 2 | + |
| 3 | +NPM release compilation uses `[self-hosted, Linux, X64, npm-build]` in the |
| 4 | +restricted `platform-npm-releases` runner group. Publishing |
| 5 | +continues on GitHub-hosted Ubuntu with OIDC; the builder receives no publishing |
| 6 | +credentials. The `npm-release-build` action is shared by releases and image |
| 7 | +validation so both compile and pack with the same setup. |
| 8 | + |
| 9 | +## Image contract |
| 10 | + |
| 11 | +`.github/runner-requirements.json` pins the complete Linux image requirements and |
| 12 | +recipe commit. The job runs `ci-image-contract verify` before compiling. The |
| 13 | +runner must have `/opt/client-codegen` matching `packages/dapi-grpc/codegen.json`. |
| 14 | +Its protobuf 3.18.1 compiler is intentionally separate from Rust's protoc 32.0. |
| 15 | +TypeScript generation comes from the workspace's pinned `ts-protoc-gen` dependency. |
| 16 | + |
| 17 | +Image-owned native dependencies are verified, never installed using sudo. Rust, |
| 18 | +Node and the pinned WASM tools use writable runner/user locations. Cargo targets |
| 19 | +remain outside the checkout; each release starts with a fresh workspace. The |
| 20 | +runner needs no Docker CLI/socket or KVM device. |
| 21 | + |
| 22 | +## Provisioning and promotion |
| 23 | + |
| 24 | +Use the reviewed `dashpay/dash-selfhosted-image` recipe and a tested immutable |
| 25 | +image digest, not a moving tag. Register dedicated release capacity with `npm-build` only after |
| 26 | +the NPM validation workflow succeeds on that image. Drain old registrations before |
| 27 | +replacement; retain their image/configuration for rollback. Old release tags |
| 28 | +still contain their original workflows and do not automatically gain this fix. |
| 29 | + |
| 30 | +Requirements-changing PRs select a candidate label bound to the complete PR head |
| 31 | +and image digest. The image controller must support the `npm` job kind and |
| 32 | +`.github/workflows/npm-runner-validation.yml`. Manifests requesting native client |
| 33 | +generation require successful Rust, Kotlin and NPM candidate jobs for promotion; |
| 34 | +skipped fork jobs do not qualify. Existing same-repository/trusted-fork guards |
| 35 | +remain in effect. |
| 36 | + |
| 37 | +The trusted `runner-image-candidate.yml` bootstrap, controller and Rust/Kotlin |
| 38 | +candidate routing must be installed on each consuming branch before candidate |
| 39 | +promotion can work. Platform PRs #4702 and #4912 establish those pieces; reconcile |
| 40 | +their requirements/selector files with this NPM extension when landing them. In |
| 41 | +particular, update both the bootstrap's reusable-workflow SHA and its |
| 42 | +`control_revision` to a reviewed image-repository revision supporting |
| 43 | +`client_codegen` and `npm`. Merely changing `recipe_revision` is insufficient. |
| 44 | +The default `v4.2-dev` and `v4.3-dev` branches must each use an explicit compatible |
| 45 | +manifest; this change does not alter an existing release tag or deploy a runner. |
| 46 | + |
| 47 | +## Verification |
| 48 | + |
| 49 | +`npm-runner-validation.yml` runs the real release build and packing action, DAPI |
| 50 | +unit tests, and a byte-for-byte check that packed Node/web clients match the |
| 51 | +freshly generated files. It uploads tarballs but never publishes them. |
| 52 | +`test-client-codegen.yml` also builds the native compilers on hosted Linux/macOS, |
| 53 | +checks committed generated output, tests failure recovery and validates packing. |
| 54 | + |
| 55 | +Local setup and generator test commands are in `packages/dapi-grpc/README.md`. |
| 56 | + |
| 57 | +## Separate PR and release state |
| 58 | + |
| 59 | +The `platform-npm-releases` organization runner group must select only the |
| 60 | +`dashpay/platform` repository and restrict execution to: |
| 61 | + |
| 62 | +```text |
| 63 | +dashpay/platform/.github/workflows/release-npm-build.yml@refs/heads/v4.2-dev |
| 64 | +``` |
| 65 | + |
| 66 | +Protect that branch with the normal maintainer review policy. `release.yml` |
| 67 | +invokes that protected reusable workflow; the reusable workflow rejects PR |
| 68 | +callers and arbitrary branch dispatches before checkout. A PR cannot select the |
| 69 | +release group by changing its own workflow to request the `npm-build` label. |
| 70 | +The group-level selected-workflow restriction is a required operator setting, |
| 71 | +not something a repository workflow can grant itself. |
| 72 | + |
| 73 | +Use separate runner containers/VMs and separate registration, workspace, HOME, |
| 74 | +Cargo registry and target-cache storage for PR and release pools. Do not mount |
| 75 | +the same cache volumes into both pools. Release caches can persist between |
| 76 | +releases; no PR may write them. Ordinary PR validation uses `npm-pr`; image |
| 77 | +candidates continue to use fresh one-job registrations and volumes. Do not add |
| 78 | +`npm-pr`, `rust-ci` or `kotlin-ci` to the release registration. |
| 79 | + |
| 80 | +For another maintained branch, create its reviewed protected reusable-workflow |
| 81 | +ref and corresponding group policy explicitly. Do not wildcard the workflow |
| 82 | +restriction or allow PR refs. Validate the policy by attempting a PR job that |
| 83 | +requests the release group: it must be rejected, while a permitted release dry |
| 84 | +run succeeds. The workflow guard is defense in depth; enabling the release |
| 85 | +pool without its group restriction does not establish this boundary. |
0 commit comments