ci: set GITHUB_REF from the caller's branch on depot ci run

[robstolarz]

The problem

depot ci run triggers a run by sending a patch of the caller's local changes plus a bare commit SHA — but no git ref. With no ref on the request, the run resolves to the GitHub event type api, and GITHUB_REF / GITHUB_REF_NAME come out empty in the CI sandbox.

That empty ref quietly breaks caching. actions/cache gates its logic on GITHUB_REF being set and non-empty (its isValidEvent check). When it's empty, the action degrades to a no-op — every lookup is a cold miss and nothing is saved — with only a buried warning in the logs to show for it. The committed-workflow path (depot ci dispatch --ref) already sends a ref and caches correctly; this brings depot ci run in line with that behavior.

See DEP-5155 for the original report.

The fix

depot ci run now forwards the caller's current local branch as a fully-qualified ref (refs/heads/<branch>) on the run request, so the sandbox has a real GITHUB_REF / GITHUB_REF_NAME to work with.

The branch is resolved with git symbolic-ref --quiet HEAD rather than git rev-parse --abbrev-ref HEAD. When a branch and a tag share a name, rev-parse can disambiguate by emitting heads/<branch>, which would then double-prefix to refs/heads/heads/<branch>. symbolic-ref returns the full ref directly and exits non-zero on a detached HEAD, so it's both unambiguous and self-signaling.

This adds a ref field (field 7, marked INTERNAL) to the RunRequest proto; the regenerated Go bindings are included.

Scope / what doesn't change

The ref only carries branch identity for the GitHub context so that GITHUB_REF / GITHUB_REF_NAME are populated. It does not change which commit is checked out — that is still driven entirely by the SHA on the request.

If the caller is on a detached HEAD or not in a git repository, no ref is sent and behavior is unchanged.

Testing

Four unit tests cover the resolution paths: default branch, feature branch, detached HEAD, and a non-repo directory. The build and existing tests are green.

---

Pairs with the api-side change that consumes the ref: depot/api#4079 (DEP-5155).

---

Note

Low Risk
CLI-only change with safe fallbacks when no branch ref exists; no auth or checkout semantics changes beyond populating optional Ref.

Overview
depot ci run now sends the caller’s current branch as refs/heads/<branch> on the CI run request when HEAD is on a branch, so the sandbox gets GITHUB_REF / GITHUB_REF_NAME and ref-gated actions like actions/cache can run instead of no-oping on an empty ref.

Branch resolution uses git symbolic-ref --quiet HEAD (not rev-parse --abbrev-ref) to avoid ambiguous names that could double-prefix to refs/heads/heads/.... The ref is identity only for GitHub context; checkout still uses the SHA on the request. Detached HEAD or non-git dirs leave Ref unset, matching prior behavior.

Adds resolveBranchRef plus unit tests for default branch, feature branch, detached HEAD, and non-repo paths.

^{Reviewed by Cursor Bugbot for commit 2649618. Bugbot is set up for automated code reviews on this repo. Configure here.}

[linear-code]

DEP-5155

[121watts]

Looks good to me. The CLI now resolves the local branch with git symbolic-ref --quiet HEAD, forwards a fully-qualified refs/heads/... value on RunRequest.Ref when available, and preserves detached/non-git behavior by omitting the field. Checkout remains SHA-driven, which matches the paired API change.

No blocking findings. One follow-up I'd consider is a command-level test that captures the final RunRequest and asserts Ref is populated alongside Sha; the helper tests and CI cover the current change well.

watts[bot]