[eas-cli] Keep the branch name in workflow:run --ref

[dennytosp]

Closes #4311.

Why

workflow:run --ref <branch> resolves the ref with git rev-parse and sends the resulting commit hash as gitRef, so the branch name never reaches the server. WorkflowRun stores requestedGitRef and gitCommitHash separately — the website's Branch column and its Git-branch filter both read requestedGitRef — so a CLI-triggered run is labelled with a 40-character hash while the same workflow started from the dashboard's Run workflow button keeps the branch name. The filter fills with hashes and stops being usable.

This was flagged during review of the PR that added --ref (#3203):

fwiw we might not do that too, one of the first things we're doing in the mutation is resolve the Git ref … (and theoretically it might be that a user's local repo knows of more refs than the remote knows about)

The local rev-parse was only meant to support --ref HEAD; it ended up applying to every ref.

What changed

resolveWorkflowRunGitRef picks what to send. Branch and tag names go through untouched, in short (my-branch) or fully qualified (refs/heads/my-branch) form. Everything else keeps being sent as the locally resolved commit, because it either has no meaning in the remote repository or does not mean the same thing there:

--ref	--symbolic-full-name	sent
my-branch, feat/x, v1.0, refs/heads/…, refs/tags/…	refs/heads|tags/…	the name
HEAD, @	refs/heads/<current>	commit
detached HEAD	HEAD	commit
HEAD~2, raw hash	(empty)	commit
origin/my-branch	refs/remotes/…	commit
heads/my-branch	refs/heads/my-branch	commit

HEAD deliberately keeps the old behaviour: it resolves to the default branch server-side, so passing it through would silently run against the wrong branch. rev-parse is still called, so an invalid ref fails exactly as before, and the log line now shows both (at my-branch (abc1234…)).

Testing

yarn typecheck                     # clean
yarn lint                          # 0 warnings, 0 errors
yarn test src/commands/workflow/   # 3 suites, 74 tests passed

12 new tests in run.test.ts. Red/green: replacing the helper body with the old return commitSha fails the 5 pass-through cases with the reported bug (Expected "my-branch", received "0e5c2f18…"), while the 7 cases that guard HEAD/detached/expression/hash/remote-tracking behaviour pass in both states.

Note: src/vcs/clients/__tests__/git.test.ts can hit its 5s per-test timeout under parallel load. That is pre-existing — it reproduces on a clean main with these changes stashed.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
packages/eas-cli/**	@douglowder
packages/eas-cli/src/commands/workflow/**	@sjchmiela

Generated by CodeMention

Warning: The preamble and epilogue options in commentConfiguration are deprecated. Use template instead.