Description of feature
subprocess.ExecCommandInput carries an Env map[string]string. No task sets it - the only caller in the tree is TestCallExecCommandWithEnv - and its behaviour differs by transport in a way that is easy to miss.
On the local path (subprocess/exec.go) the entries are merged into the child process environment and work as expected. On the SSH path (subprocess/ssh.go) they are merged into the environment of the local ssh client, which does not forward them: docket configures no SendEnv, and the server would have to opt in with AcceptEnv regardless. So a task that set Env would work under dokku apply and silently do nothing under --host - the failure mode #417 avoided by rendering its create-time options as flags instead.
ResolveCommandString also ignores Env entirely, so even on the local path the assignments would never appear in plan, apply --verbose, or the JSON commands stream, and nothing would mask a secret in them.
#417 documented the field rather than changing it. The actual decision is still open:
- remove
Env from ExecCommandInput, since nothing uses it and the flag approach covers the need
- or make it real: render the assignments onto the remote command line (
KEY= plus a syntax.Quoted value, quoting the value only so the remote shell parses it as an assignment), and teach ResolveCommandString to show them so masking applies
Removing it is the smaller change and matches how tasks reach dokku today. Keeping it half-working is the one option worth ruling out.
Description of feature
subprocess.ExecCommandInputcarries anEnv map[string]string. No task sets it - the only caller in the tree isTestCallExecCommandWithEnv- and its behaviour differs by transport in a way that is easy to miss.On the local path (
subprocess/exec.go) the entries are merged into the child process environment and work as expected. On the SSH path (subprocess/ssh.go) they are merged into the environment of the localsshclient, which does not forward them: docket configures noSendEnv, and the server would have to opt in withAcceptEnvregardless. So a task that setEnvwould work underdokku applyand silently do nothing under--host- the failure mode #417 avoided by rendering its create-time options as flags instead.ResolveCommandStringalso ignoresEnventirely, so even on the local path the assignments would never appear inplan,apply --verbose, or the JSONcommandsstream, and nothing would mask a secret in them.#417 documented the field rather than changing it. The actual decision is still open:
EnvfromExecCommandInput, since nothing uses it and the flag approach covers the needKEY=plus asyntax.Quoted value, quoting the value only so the remote shell parses it as an assignment), and teachResolveCommandStringto show them so masking appliesRemoving it is the smaller change and matches how tasks reach dokku today. Keeping it half-working is the one option worth ruling out.