User Story
As an integration-test author, I want to override named tmachine inputs at runtime, so that CI can test candidate artifacts using values that are known only when the workflow runs.
Problem Statement
Tmachine inputs are currently fixed in its generated YAML configuration. The install and test commands have no runtime input override, even though release-specific values such as the candidate image SHA are available to the workflow only at runtime.
The Debian conformance lane introduced in #3461 therefore loads candidate supervisor and sandbox images under the fixed :tmachine tag and writes those references into the test user's gateway configuration. This safely prevents the packaged gateway from resolving its embedded dev or release-version tag, but it hides the candidate image identity and couples the playbook to a synthetic tag.
Using the package's embedded image tag is not a safe replacement. Release Dev could refresh :dev from the registry and test an older published image, while Release Tag runs before the versioned images are published.
Impact / Why This Matters
The current fixed-tag override keeps conformance deterministic, but CI cannot express the actual candidate image tag through tmachine. That makes artifact provenance less obvious and creates a risk that a future cleanup removes the override and accidentally pulls a previously published image during release validation.
Regenerating the Nix-backed tmachine configuration for every workflow value would move runtime CI data into build-time configuration and make local reproduction unnecessarily difficult.
Proposed Design
Add a repeatable runtime --input NAME=VALUE option to the tmachine install and test commands. Runtime values should override matching configured inputs before tmachine hashes the install layer and invokes Ansible.
The resulting workflow should allow release CI to retain the candidate images' immutable source-SHA tags and invoke tmachine with an override such as:
tmachine test ubuntu-docker-rootful deb conformance \
--input openshell_runtime_image_tag="$SOURCE_SHA"
The Debian installer can then write the source-SHA image references into its minimal per-user gateway configuration. The packaged systemd unit and all other built-in gateway defaults remain unchanged.
Acceptance Criteria
Alternatives Considered
- Keep the fixed
:tmachine alias. This is deterministic but obscures which candidate image is under test and leaves the workflow coupled to a synthetic name.
- Use the image tag embedded in the packaged gateway. This can pull an older
dev image, and versioned release images are not published until after conformance succeeds.
- Generate a new tmachine configuration in CI. This mixes runtime workflow values into Nix evaluation and makes equivalent local invocations harder to reproduce.
Agent Investigation
Tmachine currently stores installer and testsuite inputs as BTreeMap<String, PathBuf>. Existing paths are canonicalized before becoming Ansible extra variables; nonexistent paths are already passed through as literal values. Installer inputs are also part of the cached install-layer hash, so runtime overrides must be applied before both hashing and playbook execution.
Related to #3454 and follow-up to #3461.
User Story
As an integration-test author, I want to override named tmachine inputs at runtime, so that CI can test candidate artifacts using values that are known only when the workflow runs.
Problem Statement
Tmachine inputs are currently fixed in its generated YAML configuration. The
installandtestcommands have no runtime input override, even though release-specific values such as the candidate image SHA are available to the workflow only at runtime.The Debian conformance lane introduced in #3461 therefore loads candidate supervisor and sandbox images under the fixed
:tmachinetag and writes those references into the test user's gateway configuration. This safely prevents the packaged gateway from resolving its embeddeddevor release-version tag, but it hides the candidate image identity and couples the playbook to a synthetic tag.Using the package's embedded image tag is not a safe replacement. Release Dev could refresh
:devfrom the registry and test an older published image, while Release Tag runs before the versioned images are published.Impact / Why This Matters
The current fixed-tag override keeps conformance deterministic, but CI cannot express the actual candidate image tag through tmachine. That makes artifact provenance less obvious and creates a risk that a future cleanup removes the override and accidentally pulls a previously published image during release validation.
Regenerating the Nix-backed tmachine configuration for every workflow value would move runtime CI data into build-time configuration and make local reproduction unnecessarily difficult.
Proposed Design
Add a repeatable runtime
--input NAME=VALUEoption to the tmachineinstallandtestcommands. Runtime values should override matching configured inputs before tmachine hashes the install layer and invokes Ansible.The resulting workflow should allow release CI to retain the candidate images' immutable source-SHA tags and invoke tmachine with an override such as:
The Debian installer can then write the source-SHA image references into its minimal per-user gateway configuration. The packaged systemd unit and all other built-in gateway defaults remain unchanged.
Acceptance Criteria
tmachine installaccepts repeatable--input NAME=VALUEoverrides.tmachine testaccepts the same overrides for the installer phase.config.yaml.:tmachineimage references.devor release-version runtime images from the registry.Alternatives Considered
:tmachinealias. This is deterministic but obscures which candidate image is under test and leaves the workflow coupled to a synthetic name.devimage, and versioned release images are not published until after conformance succeeds.Agent Investigation
Tmachine currently stores installer and testsuite inputs as
BTreeMap<String, PathBuf>. Existing paths are canonicalized before becoming Ansible extra variables; nonexistent paths are already passed through as literal values. Installer inputs are also part of the cached install-layer hash, so runtime overrides must be applied before both hashing and playbook execution.Related to #3454 and follow-up to #3461.