etna workload add --ref <sha> fails because git clone --branch only accepts branch/tag names

Repro

etna workload add https://github.com/alpaylan/cedar-etna.git --ref f332c2c161884f0a3d1b7484e0abff8b84694ece

Output

fatal: Remote branch f332c2c161884f0a3d1b7484e0abff8b84694ece not found in upstream origin
Error: Aborting run due to an error (at src/cli.rs:251)

Caused by:
    git clone https://github.com/alpaylan/cedar-etna.git failed with status exit status: 128

Cause

service/workload.rs invokes git clone --branch <ref> (or equivalent) where the --branch argument is the user-supplied --ref. git clone --branch only accepts a branch or tag name, not a commit SHA. So --ref <sha> always fails even when the SHA is reachable from the default branch.

Why it bites

The pattern etna workload add <repo> --ref ${{ github.sha }} is the natural thing to write in a CI workflow that wants the workload to mirror the exact commit being built. It quietly works when the runner happens to be on a tag (refs/tags/...) or branch tip, but fails on every other commit including all push-to-main SHAs.

Fix sketch

git clone (no --branch) followed by git checkout <ref> if --ref is set. Detection of branch-vs-tag-vs-sha can be cheap (git rev-parse --quiet --verify) or skipped — git checkout resolves all three forms transparently.

Workaround

Drop --ref entirely if you want HEAD of the default branch. That's what cedar-etna's canary workflow does today.

Reference run

https://github.com/alpaylan/cedar-etna/actions/runs/25091418284

Start in service/workload.rs, where the workload clone uses the supplied --ref, and inspect the error path referenced in src/cli.rs:251. Reproduce with the SHA from the issue, then verify that branch, tag, and commit refs work through etna workload add without changing the default-branch behavior.