No description
19d5c6eecb
Two-layer bug, found while diagnosing why chromium-fork's sccache/MinIO
credentials never reached the remote autoninja invocations in ci runs
#69/#70 (which use exactly this pattern: -env AWS_ACCESS_KEY_ID -env
AWS_SECRET_ACCESS_KEY -- 'export ... && autoninja ...'):
1. buildPayload() only ever built the env map inside its -script branch.
The plain -- <cmd> branch returned remotePayload{command: ...} with
env left nil -- so -env flags on a -- <cmd> invocation were silently
accepted by the CLI parser and then just... dropped. No forwarding,
and no validation that the named vars even existed locally either
(LookupEnv was never called for this path at all).
2. Even had (1) not existed, sshExec (the function -- <cmd> actually
calls) took no env parameter whatsoever -- there was nowhere for a
populated env map to go. sshExecScript (the -script path) already
prefixed `export KEY=value` lines onto its script correctly; sshExec
never did anything equivalent.
Fixed both: buildPayload now builds env unconditionally before branching
on script-vs-command, and sshExec now accepts env and prefixes `export
KEY='value'; ` onto the command string, mirroring sshExecScript.
Verified against a real box: `-env TESTVAR -- 'echo "TESTVAR=$TESTVAR"'`
printed empty before this fix, prints the real value after.
|
||
|---|---|---|
| .gitignore | ||
| CHALLENGES.md | ||
| go.mod | ||
| go.sum | ||
| install-deps.sh | ||
| main.go | ||
| stall-watch.py | ||
| sync.sh | ||