Skip to content

v0.194.0

Choose a tag to compare

@github-actions github-actions released this 28 Oct 17:49
· 24 commits to main since this release

What the 0.193.0 ship measured: 53 minutes end to end (cold push 1040 s, hosted checks 743 s, the early gate about 29 minutes of which the closure is most, merge 6 s, post-merge verify 2 s, tag 2 s, release workflow 316 s, npm check 90 s and reported PENDING until --resume, which then confirmed it). The post-merge verify and the tag are now seconds; the early gate and a cold push are what is left.

  • The closure's steps run three at a time. scripts/release-closure.mjs --run --jobs N (or AGENTIC_SECURITY_CLOSURE_JOBS) runs the steps side by side, each in its own process group, with the step that rebuilds dist in place (bundle-source) first and alone, and records the steps in plan order, so the record, its digest and its verification are the same as a serial run's. ship sets three for the early gate. Measured once, in a separate worktree on an idle machine: 394 s, against 1062 s serial in the 0.192.0 run. In that worktree the bundle-source step failed and the tree was reported dirty (stray build chunks in the worktree), so that figure is a timing of the steps, not a passing closure; the real-checkout measurement is the next TIMINGS line. The serial path is unchanged and is the default.

  • test:loop runs three files at once instead of one. It is the longest closure step (567 s serial). One run of the whole suite passed 225 of 225 in 298 s. It contains real-time heartbeat and staleness tests, so a run on a loaded machine could flake; that has been run once, not characterised.

  • The backfill script no longer moves the "Latest" badge. Pages it creates are for old versions and are created with --latest=false; before, each one took the badge from the newest release and it had to be put back by hand.

  • The haskell:9 container image, first real-engine run: it failed, and the fault was found and fixed. The proof-container job (which now pulls haskell:9 and sets AGENTIC_SECURITY_PROOF_CONTAINER_HASKELL=1) failed on this pull request's first run with missing toolchain: ghc: the image keeps GHC in /opt/ghc/<version>/bin, and the container PATH named a directory that does not exist. containerArgs now resolves the versioned directory inside the container (a fixed sh -c wrapper, the argument vector unchanged after it). Run locally against a real engine after the fix (Docker 29.5.2 on Colima, macOS arm64, one round, with the scratch directory under $HOME because Colima shares nothing else): all four Haskell classes confirm the vulnerable fixture (4 of 4) and none confirms the mitigated one (0 of 4). That is a first macOS data point, one engine, one round. The second hosted run then failed the same way for a different reason, which the local run could not show because the maintainer's machine has GHC installed: runAttempt judged a container run by the HOST's toolchain, so every Haskell proof was unsupported on a runner without GHC however good the image. The toolchain check now follows where the program runs (the image's tools for a container, the host's otherwise), with a test that a host with no GHC still gets a container attempt and that the same host is still unsupported for a local run. Whether the hosted Linux job now passes is that job's result on this pull request; the skip in measure.mjs stays until it has.

  • @vscode/vsce 4.1.0 in the VS Code extension (a newly published version made the dependency-currency check fail on the pull request).

  • A failed blocking check now stops ship at once. It used to wait until every workflow run had finished, including the 40 minute informational local-model job, so a failure at minute 5 was reported at minute 39 (this release's first attempt). It now stops when no blocking check is pending and nothing was just re-run. The closure, run three steps at a time in the real checkout during that attempt, took 412 s with every step passing on a clean, stable tree (1062 s serial in 0.192.0).

  • A real second labeller on the fresh Haskell set, and what it showed. The fresh set's 222 sites were labelled again by a different model, blind (bench/dag/dev-haskell/fresh-labels-second.json, second-labeler-score.mjs, section in that README). Agreement is 92.8% and Cohen's kappa 0.40. Twelve of the 16 disagreements are one unwritten policy: the first labeller counted vulnerabilities in example programs and a test server as true positives, the second did not. Scored by the second labeller's reading the fresh set has 7 true positives, not 21, so the recorded fresh precision of 17 of 45 depends on that policy. Nothing about the engine changed; the measurement's weak point is now on record. It was one pass with no adjudication, and one of the two sessions used 7 tool calls for 111 sites, so its reading depth is not established.

  • The gitit password-hashing patch, type-checked against real packages, in isolation. Building gitit itself is not possible on this host: cabal cannot resolve its dependencies under GHC 9.14 (feed requires base < 4.22), so no whole-project compile was run. The patched hashPassword function alone (PBKDF2 from cryptonite 0.30, hex from base16-bytestring 1.0.2.0, both installed from Hackage) type-checks with ghc -fno-code. That says the API calls are real, not that the patch is safe to apply: existing stored hashes would stop verifying, which is why the fixer still refuses the class.

Not done: a cold push still runs the whole local suite when a gate script changes (17 minutes in 0.193.0); the duplicate closure steps (compat-corpus, compat-layer-recall) still run locally as well as in hosted CI; per-test line coverage for test selection is unbuilt.