fix: preserve --variable values through interactive runbook run

[NickJosevski]

Fixes #582.

The bug

octopus runbook run with --variable Name:Value works correctly under --no-prompt, but in interactive mode the -v values are silently dropped — both from the printed Automation Command and (per the reporter) from the actual run, which falls back to the prompted variables' default values.

Reproduction from #582:

octopus runbook run -p "New Project" -n "Runbook" -s "Kenny" -v "certCommonName:CLI" -v "prompt:CLI" -e "Development"

Output (note the missing -v in the Automation Command):

Automation Command: octopus runbook run --project 'New Project' --name 'Runbook' --environment 'Development' --no-prompt

Workaround was passing --no-prompt explicitly.

Root cause

Inside askRunbookPreviewVariables (pkg/cmd/runbook/run/run.go), the result map was built fresh by iterating over the form preview's controls (flattenedControls) and only adding entries for controls. Any CLI-supplied variable whose name didn't match a control was discarded. The caller then assigned this map back over options.Variables, losing the originals.

--no-prompt skips this codepath entirely, which is why the workaround works.

Fix

Extract the variable-resolution logic into a pure helper, resolveRunbookPreviewVariables, and seed the result map with the caller-supplied CLI variables before processing controls. Variables that match a control are still canonicalised to the control's name (preserving the prior case-fixing behaviour); variables without a matching control are now passed through unchanged.

Tests

Added pkg/cmd/runbook/run/preview_variables_test.go (internal package run) covering:

• CLI variable with no matching control is preserved in the result (the bug fix).
• CLI variable matching a control with different casing is canonicalised to the control's name, with no duplicate entry.
• A required control with a CLI value supplied does not trigger a prompt.
• Sensitive controls are still reported in the sensitive-variable list.
• A required control with no CLI value still triggers the prompt (existing path, not regressed).
• Combination: one matching-with-casing-fix variable plus one passthrough variable.

Notes

• A near-identical pattern exists in pkg/cmd/release/deploy/deploy.go around line 854. Not changed in this PR to keep the scope to the reported issue; happy to follow up.
• Local go test wasn't run in the environment this was authored in (no Go toolchain). Relying on CI to verify.

Test plan

• CI passes go test ./pkg/cmd/runbook/run/... including the new unit tests.
• Manual repro from Prompted variable value arguments are stripped from runbook run command #582: run the original command interactively and confirm both the Automation Command output and the actual run carry the -v values.
• Confirm --no-prompt path is unaffected by running an existing automation-mode invocation.
• Sanity-check the Git-runbook path (askRunbookPreviewVariables is shared between DB and Git runbooks).

🤖 Generated with Claude Code