@ai-ecoverse/slicc-bios 1.8.2 → 1.9.0

package/README.md

@@ -461,7 +461,11 @@ Limits:
 
 [`.github/workflows/canary.yml`](.github/workflows/canary.yml) answers "is bios main green with these candidate versions?" before anyone asks for a pin. It never pushes, pins or opens a PR: it reports.
 
-- **Triggers:** `workflow_dispatch` and `workflow_call` with `overrides`, a JSON list of `name@version` (`["@ai-ecoverse/slicc-kernel@1.81.0"]`), and optionally `runner`, `shards` (names from [`scripts/canary/shards.json`](scripts/canary/shards.json); ci.yml's `follow-chat`, `remote-pydata`, `users-agent-ui`, `packages-update-cdp`, `guard`, `k4-link` and `rest` by default, or `sweep` for just the base-set sweep and the certs check), `expect` and `bios-ref` (any branch or sha of slicc-bios: the shard jobs check it out and lay this ref's `scripts/canary`, and `sweep.test.mjs` if it has none, over it; a ref whose `pins.test.mjs` has no canary mode gets the candidates in its working copy of `certs.json` instead, and the report still lists them as candidates). A proof in `proofs.json` can name its own `ref` the same way. An hourly `schedule` checks npm's `latest` of every kernel, jsh, cdp, agent, `wasm-*`, `wasi-*`, `wasix-*` and `py-*` package that a `src/packages/**/package.json` pins, and runs once with every newer one as the overrides, only when that list differs from the last scheduled canary's (its inputs are kept in the Actions cache). A `pull_request` trigger, filtered to the canary's own files, runs the proof in [`scripts/canary/proofs.json`](scripts/canary/proofs.json) from one plan job, cancelling a superseded run: kernel 1.78.0 on the `sweep` shard must regress grep, sed, jq, xz, findutils, diffutils and patch with exit 70 (kernel #483).
+- **Triggers:** `workflow_dispatch` and `workflow_call` with `overrides`, a JSON list of `name@version` (`["@ai-ecoverse/slicc-kernel@1.81.0"]`), and optionally `runner`, `shards` (names from [`scripts/canary/shards.json`](scripts/canary/shards.json); ci.yml's `follow-chat`, `remote-pydata`, `users-agent-ui`, `packages-update-cdp`, `guard`, `k4-link` and `rest` by default, or `sweep` for just the base-set sweep and the certs check), `expect` and `bios-ref` (any branch or sha of slicc-bios: the shard jobs check it out and lay this ref's `scripts/canary`, and `sweep.test.mjs` if it has none, over it; a ref whose `pins.test.mjs` has no canary mode gets the candidates in its working copy of `certs.json` instead, and the report still lists them as candidates). A proof in `proofs.json` can name its own `ref` the same way. An hourly `schedule` checks npm's `latest` of every kernel, jsh, cdp, agent, `wasm-*`, `wasi-*`, `wasix-*` and `py-*` package that a `src/packages/**/package.json` pins, and runs once with every newer one as the overrides, only when that list differs from the last scheduled canary's (its inputs are kept in the Actions cache). A `pull_request` trigger, filtered to the canary's own files, runs the proof in [`scripts/canary/proofs.json`](scripts/canary/proofs.json) from one plan job, cancelling a superseded run: kernel 1.78.0 on the `sweep` shard must regress grep, sed, jq, xz, findutils, diffutils and patch with exit 70 (kernel #483). A second proof packs `@ai-ecoverse/slicc-cdp@1.26.2` with `npm pack`, uploads it from the plan job, and runs it as a candidate artifact on `packages-update-cdp` and `guard` with `repeat: 3`.
+- **A candidate from another repo's run:** `candidate-package` (the package it replaces, `@ai-ecoverse/slicc-cdp`), `candidate-artifact` (an artifact holding one `npm pack` tarball of it), `candidate-run` (the run that uploaded it), `candidate-sha256` and optionally `candidate-repo` (the caller's repository by default). Each shard job downloads the artifact with `github.token`, which under `workflow_call` is the caller's, so the caller's job needs `actions: read`. [`override-pins.mjs`](scripts/canary/override-pins.mjs) checks the tarball's sha256 before it reads anything and refuses a mismatch, then checks the tarball is that package with an exact version. It seeds the harness download cache with the bytes at the npm URL of that version, and rewrites the pins and locks through a local registry that serves npm's packuments with that version added, so an unpublished `x.y.z-pr.N.M` locks like a published one (npm's lock gets the registry URL back). Everything else stays a registry version. The report lists it as `candidate (artifact <run>/<name>, sha256 …)`.
+- **`repeat`** (1 to 10, default 1): each selected test file runs that many times with the candidates, and the files with a failure run that many times on main's pins. A test failing in every candidate run and no baseline run is a regression, one failing in every run of both is a failure on both, and anything mixed is flaky. Each row carries its counts, `candidate 2/3, baseline 0/3`.
+- **`result`**, a `workflow_call` output next to `ok`: the JSON summary (`ok`, `counts`, `regressions`, `both`, `flaky`, `failures`, `missingShards`, `unexplainedExits`, `candidates`, `overrides`, `repeat`) plus the `canary` artifact's name and URL.
+- **Permissions:** `contents: read` and `actions: read`, no secrets and no `id-token`. A caller outside bios runs the plan with its inputs: the PR proofs and the hourly npm check run only for bios's own triggers.
 - **Jobs:** one plan job, one job per shard of each run, and one report job, because the queue for a runner costs more than the work.
 - **Runner:** fork code never runs on the org's Cloud Run pools. A same-repo `pull_request` (the proofs from our own branches), or a `schedule`, `workflow_dispatch`, `workflow_run` or `release` run on `main` (any `bios-ref`), puts the shard jobs on the `runner` input, else the `CERT_RUNNER` repository variable (`cloud-run-bench`), and the light plan and report jobs on `CERT_LIGHT_RUNNER` (`cloud-run`). Everything else runs on `ubuntu-latest`, and the `runner` input is ignored: fork pull requests, and dispatches from any other branch. Under `workflow_call` the same check reads the caller's event. The pools run with "no new privileges", so `sudo` can't become root there: the shard job installs Chromium's system libraries only when `sudo -n true` works, and otherwise relies on the image's.
 - **Pins:** [`scripts/canary/override-pins.mjs`](scripts/canary/override-pins.mjs) `name@version …` fetches each tarball through the harness download cache (so the tests find it there), checks it against npm's sha512 and records its sha256. It sets the version in every `package.json` under `src/packages` that pins the package and lets npm (`--package-lock-only`) and pnpm 12 (`--lockfile-only`) rewrite that directory's lockfiles, so a dependency that moves with the package (an agent release taking a newer slicc-browsers) moves in the lock too. A package that is only a dependency in a pnpm lock is forced with an `overrides` entry in that directory's `pnpm-workspace.yaml`. One that is only a dependency in an npm lock (wasm-git's own wasm-bash in the optional catalog) is left alone and reported as held. It writes `node_modules/.cache/slicc-canary/pins.json`, whose `candidates` are the gated packages the locks now pin that `certs.json` doesn't certify.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.8.2",
+  "version": "1.9.0",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",