actions/setup wiring for wizen (#85): smoke the installed-tools path - #87
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
actions/setupwiring checkbox from #85, reshaped by #86: there is no separatewizer-preinittool to install anymore — setup's existingcomponent-test-cliinstall carrieswizen(andcompose-runner/run), because the CLI hardwires the runner crate'swizerfeature.What this adds:
test -x: builds the sample suite, wizens it (the one-line Productize wizer pre-initialization: library entry point, setup action, discoverability #85 CI path), holds the committed lockfile against the wizened artifact (finding Runner execution-policy guidance #22 through installed binaries), and reproduces both runner goldens from it —ct-runnerandcomponent-test run --jsonl, the latter with no wac and no wasmtime CLI anywhere in the job.wizen: trueinput deliberately lands nowhere for now: setup runs before the consumer's suite artifacts exist, and the action it belongs to (run-suite) is parked pending a second consumer — noted on that bullet so the flag arrives with it.Verified locally with real
cargo install --locked --pathinstalls of both tools into a scratch root: wizen →lock --check→ ct-runner golden →run --jsonlgolden, all byte-exact. The smoke job on this PR is the same assertion under Actions viasource-path.