`$gitShortSha()` returns git error message as version string when not in a git repo

[zainforbjs]

Describe the bug
When running wheels deploy from a directory that is not a git repository, the version string becomes "fatal: not a git repository (or any of the parent directories): .git" instead of a short SHA. The $gitShortSha() method merges stderr into stdout via redirectErrorStream(true) and reads the output without checking the git process exit code.

To Reproduce
Steps to reproduce the behavior:

1. Create a new app directory without git:

wheels new testapp && cd testapp

2. Run wheels deploy init and configure deploy.yml.
3. Run wheels deploy.
4. See output: Deployed testapp version fatal: not a git repository (or any of the parent directories): .git to 1 host(s): ...

Expected behavior
When not in a git repo, the version should gracefully fall back to "unknown" (or similar). The deploy should not fail or produce a broken version string.

Desktop

• OS: macOS

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened / what I expected" (Deployed testapp version fatal: not a git repository ... to 1 host(s)), a precise reproduction (wheels new → wheels deploy init → wheels deploy), and even names the root cause: $gitShortSha() calls pb.redirectErrorStream(true) and reads the merged output without checking the git process exit code.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns. The deploy subsystem lives under cli/lucli/services/deploy/.

Fix sketch

The $gitShortSha() helper is duplicated in two places:

• cli/lucli/services/deploy/cli/DeployMainCli.cfc:495 — calls pb.redirectErrorStream(true), so when git rev-parse --short HEAD fails outside a repo, the stderr text (fatal: not a git repository ...) is what gets returned and ends up as the version label.
• cli/lucli/services/deploy/cli/DeployBuildCli.cfc:142 — doesn't merge stderr, but also never checks the exit code; on failure it would return an empty/whitespace string rather than a sensible fallback.

The mechanical fix is the same in both: capture the int returned by proc.waitFor() (or read proc.exitValue()) and return "unknown" when it is non-zero, before trimming the buffered stdout. In DeployMainCli.cfc additionally drop the pb.redirectErrorStream(true) line so stderr doesn't poison the success path. The existing try/catch (any e) { return "unknown"; } wrapper already establishes the right fallback value to reuse. No callers need to change — DeployMainCli.cfc:60 and the three callsites in DeployBuildCli.cfc already treat the return as an opaque version string.

Confidence: medium

Auto-downgraded from high because the fix touches the deploy subsystem (per the auto-downgrade rule); the report itself is unambiguous and the fix shape is mechanical.

<!-- wheels-bot:triage:2671 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (cli/lucli/services/deploy/** — both DeployMainCli.cfc:495 and DeployBuildCli.cfc:142 per the triage sketch) and the bot's safety net requires a human in the loop before any code is written.