test(cli): pin deploy init scaffold env.secret round-trip (#3158)

[bpamiri]

What

#3158 reported that wheels deploy init scaffolds an env.secret: [WHEELS_RELOAD_PASSWORD] block (cli/lucli/templates/deploy/init/deploy.yml.mustache) that, since the #3008 $rejectEnvSecrets guard, hard-failed any non-empty env.secret with Wheels.Deploy.EnvSecretUnsupported — so the freshly-scaffolded config couldn't be deployed without manual editing.

Verify-first finding

The premise is already resolved on develop by #3167 (df62f4683), which:

• removed Base.$rejectEnvSecrets (grep finds zero rejectEnvSecrets/EnvSecretUnsupported references anywhere in cli/), and
• implemented env.secret delivery via a remote --env-file (created at 600 perms, content over SFTP only, referenced by docker run --env-file).

So the scaffolded env.secret block is now correct — the issue's original "remove the block" direction would now break a shipped feature. The fix reduces to pinning the round-trip so the scaffold and the deploy engine can't drift apart again. No template or engine change is needed.

Reproduced empirically on the lucee7 docker harness:

• The scaffold's .kamal/secrets declares WHEELS_RELOAD_PASSWORD= (empty); the SecretResolver still exports it (structKeyExists true), so env_file_content() does not raise EnvSecretMissing.
• A fresh init → config() → deploy --dry-run succeeds and routes the secret through --env-file .kamal/apps/<service>/env/roles/<role>.env.

Change

Two DeployMainCliSpec regression tests:

1. the init scaffold round-trips through config() and deploy --dry-run with no EnvSecretUnsupported/EnvSecretMissing, and the dry-run references the --env-file path;
2. a deploy of the scaffold delivers WHEELS_RELOAD_PASSWORD to the role env file over SFTP (FakeSshPool uploadString), never in argv.

Red-proof: both tests fail if the scaffold drops its env.secret block (verified by temporarily removing it from the template), so they genuinely guard the scaffold→delivery contract.

Plus a changelog.d fixed fragment.

Tests

CLI suite (lucee7 docker harness): 1071 pass / 0 fail / 2 tolerated docker-env artifacts (SshClientSpec/SshPoolSpec require docker-in-docker, pre-existing/environmental). DeployMainCliSpec 66 → 68 pass.

Fixes #3158

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer

TL;DR — This PR pins the wheels deploy init scaffold to the deploy-engine env.secret contract (#3158) with two DeployMainCliSpec regression tests plus a fixed changelog fragment. No production code changes: the underlying fix landed in #3167 (remote --env-file delivery), so this is purely a guard against future drift. I re-verified every API the new tests touch against the actual deploy engine and everything lines up. Verdict: approve.

Tests

The two new specs are well-targeted and accurately model the real engine:

• DeployMainCliSpec.cfc:357 — round-trip test. Constructor new DeployMainCli(fake, {projectRoot: tmpCwd}) matches DeployMainCli.cfc:17 init(any sshPool = "", struct opts = {}); init_stub({cwd, service, image}) matches DeployMainCli.cfc:469; deploy({..., dryRun: true}) is honored (DeployMainCli.cfc:73 var dryRun = arguments.opts.dryRun ?: false). The expect(arrayLen(fake2.calls())).toBe(0) assertion correctly encodes "dry-run issues no SSH calls."
• DeployMainCliSpec.cfc:391 — delivery test. The asserted env-file path .kamal/apps/demo/env/roles/web.env matches the engine layout (AppCommands.cfc:158 .kamal/apps/<service[-destination]>/env/roles/<role>.env, default role web, no destination). The uploadString call-record fields the test reads (.remote, .content) and the c.cmd scan match FakeSshPool.cfc:179-181. The "value never in argv" loop is a genuine secret-leak guard.

Red-proof is documented in the PR body (both fail if the scaffold drops its env.secret block), so they exercise the contract rather than passing vacuously.

Conventions

• (##3158) in the it() descriptions correctly escapes to a literal # — matches existing prior art in the same file ((##3085) at DeployMainCliSpec.cfc:33). The #chr(10)# interpolation in the secrets-file write is a proper expression, not the comment/#-escape hazard.
• These are CLI-runtime specs (cli/lucli/tests), outside the vendor cross-engine matrix, so the Lucee/Adobe/BoxLang invariants do not apply here.

Docs

• Minor, non-blocking: changelog.d/3158-deploy-init-envsecret-roundtrip.fixed.md is a fixed fragment, but the actual user-facing fix shipped in #3167 — this PR only adds the regression tests. The wording reads slightly as if this PR performed the fix. It is defensible (it documents real now-pinned behavior and the slug/type follow the convention), so not a change request — just flagging in case you would prefer it phrased as "regression coverage for the #3167 fix."

Commits

test(cli): pin deploy init scaffold env.secret round-trip (#3158) — valid type, scope, subject length, casing. Good.

Clean test-only change with verified API usage and red-proofed coverage. Approving.