From ad2af0b161c9c53a3cf31aa68e4f9dd98fe0f946 Mon Sep 17 00:00:00 2001
From: Lann Martin <lmartin@akamai.com>
Date: Tue, 11 Aug 2026 12:20:24 -0400
Subject: [PATCH] actions/setup wiring for wizen (#85): smoke the
 installed-tools path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The checkbox predates the CLI subsuming wizer-preinit: there is no
separate tool to install anymore — actions/setup's existing
component-test-cli install carries wizen (and compose-runner/run)
because the CLI hardwires the runner crate's `wizer` feature. What
was left of the wiring:

- actions-setup-smoke now exercises the installed binaries the way a
  consumer's CI would, not just `test -x`: build the sample suite,
  wizen it (one line, the #85 CI path), hold the committed lockfile
  against the wizened artifact (finding #22 through installed
  binaries), and reproduce both runner goldens from it — ct-runner
  and `component-test run --jsonl`, the latter with no wac and no
  wasmtime CLI anywhere in the job.
- actions/README.md documents the surface the installed CLI brings
  and the one-line wizening recipe, with the mixing-artifacts caveat.
- The considered `wizen: true` input lands nowhere for now, on
  purpose: setup runs before the consumer's artifacts exist, and the
  action it belongs to (run-suite) is deliberately parked; noted on
  its bullet so the flag arrives with it.

Step logic verified locally with real `cargo install --locked --path`
installs of both tools into a scratch root: wizen -> lock --check ->
ct-runner golden -> run --jsonl golden, all byte-exact.
---
 .github/workflows/ci.yml | 28 +++++++++++++++++++++++++++-
 actions/README.md        | 20 +++++++++++++++++++-
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 3ce0353..94033c8 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -111,7 +111,9 @@ jobs:
   # consumer Cargo.lock pins this very commit, the action installs the
   # tools from the checkout (source-path), and its pins gate must hold
   # the fixture to that rev. Asserts the advertised outputs and bin
-  # names on top.
+  # names, then drives the installed binaries over a built suite the
+  # way a consumer's CI would — including the wizen path (#85), which
+  # ships inside the CLI rather than as a separate tool.
   actions-setup-smoke:
     runs-on: ubuntu-latest
     timeout-minutes: 20
@@ -152,3 +154,27 @@ jobs:
           test "${{ steps.setup.outputs.rev }}" = "${{ github.sha }}"
           test -x "${{ steps.setup.outputs.bin }}/component-test"
           test -x "${{ steps.setup.outputs.bin }}/ct-runner"
+
+      - name: Build the synthetic consumer's suite artifact
+        run: cargo build --target wasm32-wasip2 --release -p sample-suite
+
+      - name: Exercise the installed tools on the suite
+        # The post-setup consumer path, via the installed binaries only
+        # (no wac, no wasmtime CLI in this job): wizen the artifact
+        # (#85 — one line in a consumer's CI), hold the committed
+        # lockfile against it (inventory survives pre-init, finding
+        # #22), then reproduce both runner goldens from it — the
+        # host-embed runner and the CLI's composed `run` leg.
+        run: |
+          set -euo pipefail
+          bin="${{ steps.setup.outputs.bin }}"
+          suite=target/wasm32-wasip2/release/sample_suite.wasm
+          wizened="$RUNNER_TEMP/consumer/sample_suite.wizened.wasm"
+          "$bin/component-test" wizen "$suite" -o "$wizened"
+          "$bin/component-test" lock "$wizened" --check components/sample-suite/tests.lock
+          out=$("$bin/ct-runner" "$wizened") && code=0 || code=$?
+          test "$code" -eq 1
+          diff expected/verify-embed-sample.txt <(printf '%s\n' "$out")
+          out=$("$bin/component-test" run --jsonl "$wizened") && code=0 || code=$?
+          test "$code" -eq 1
+          diff expected/verify-compose-sample.jsonl <(printf '%s\n' "$out")
diff --git a/actions/README.md b/actions/README.md
index b9e8ccc..8d15336 100644
--- a/actions/README.md
+++ b/actions/README.md
@@ -32,6 +32,23 @@ fails the run (branch/tag refs skip with a notice).
 `source-path: .` installs from a checkout instead of `--git` (used by
 this repository's own CI smoke, and the local-override analogue).
 
+The installed CLI carries the whole composition/execution surface —
+`wizen` (pre-initialize large suites, #25/#85), `compose-runner`, and
+`run` (embedded reference provider, runner core, and wasmtime) — so a
+consumer pipeline that only needs the composed path installs no wac
+and no wasmtime. Wizening in CI is one line after setup, on the built
+artifact:
+
+```sh
+target/ct-tools/bin/component-test wizen suite.wasm -o suite.wasm
+```
+
+(Run the wizened artifact everywhere downstream — runners and
+`lock --check` alike; mixing artifacts is the failure mode.) There is
+deliberately no `wizen:` input on this action: setup runs before the
+consumer's suite artifacts exist. When a run-suite action materializes
+(below), wizening belongs there as an input.
+
 ### The local half: one canonical `_ct-tools` recipe
 
 CI is only half the bootstrap; local `just` runs need the same tools.
@@ -112,7 +129,8 @@ red. The action adds presentation, never verdict.
 - **run-suite** (execute a suite artifact on a runner kind, upload
   results): deliberately parked until a second consumer exists — the
   generic/specific line for SUT-linked drivers, artifact caches, and
-  browser-leg fallbacks is not knowable from one data point.
+  browser-leg fallbacks is not knowable from one data point. #85's
+  `wizen: true` flag lands here as an input when it exists.
 - **publish-viewer** as a *reusable* action: the viewer deploy is a
   workflow in this repository for now (`.github/workflows/pages.yml`);
   generalizing it needs the same second data point.