eas workflow:run --ref discards the branch name (resolved to a SHA locally before dispatch)

[marco242424]

Summary

eas workflow:run --ref <branch> resolves the ref locally with git rev-parse and sends only the resulting SHA, so the branch name never reaches the server. Triggering the same workflow from the dashboard's "Run workflow" button stores the branch name correctly, so the branch is lost on the CLI path only.

Managed or bare?

Managed (CNG) — ios/ and android/ are gitignored and generated by prebuild.

Note: npx expo-env-info reports "bare" because the directories exist locally after a prebuild. Not relevant to this issue, which is CLI-side only.

Environment

  expo-env-info 2.1.0 environment info:
    System:
      OS: macOS 26.6.2
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 26.3.0
      Yarn: 1.22.22
      npm: 11.16.0
      Watchman: 2026.06.08.00
    Managers:
      CocoaPods: 1.17.0
    IDEs:
      Xcode: 26.6/17F113
    npmPackages:
      expo: ~57.0.18 => 57.0.18
      expo-router: ~57.0.17 => 57.0.17
      react: 19.2.3 => 19.2.3
      react-native: 0.86.3 => 0.86.3
    npmGlobalPackages:
      eas-cli: 23.0.0

npx expo-doctor: 21/21 checks passed. No issues detected!

Error output

No error. The run succeeds; the branch name is silently dropped.

Reproducible demo or steps to reproduce from a blank project

1. Create a blank Expo project, link it to a GitHub repo in EAS project settings, and push a branch named e.g. my-branch.
2. Add any workflow file, e.g. .eas/workflows/build.yml with a single type: build job.
3. Run: eas workflow:run build.yml --ref my-branch
4. In the dashboard, open Workflows. The run's Branch column shows a 40-character commit SHA, not my-branch. The Git branch filter fills with hashes and becomes unusable. On the Builds page, Git ref shows only the SHA.
5. Now trigger the same workflow via the dashboard's Run workflow button, selecting my-branch. That run shows my-branch in the same column.

Both runs have triggerEventType: MANUAL and build the same commit — only the CLI path loses the branch.

Cause

In packages/eas-cli/src/commands/workflow/run.js (built output), gitRef is reassigned to the output of git rev-parse flags.ref:

gitRef = (await spawnAsync('git', ['rev-parse', flags.ref], { cwd: projectDir })).output[0].trim();

and only that resolved value is passed to createWorkflowRunFromGitRefAsync. The original string survives only in error messages (at ${flags.ref}).

No input avoids this, since rev-parse collapses a branch name, a qualified ref (refs/heads/...) and HEAD to the same hash.

Since the dashboard path stores and renders branch names correctly, the server clearly handles them fine. Could the CLI send the original ref alongside the resolved SHA?

Side effect

github.ref_name resolves to the SHA on CLI-dispatched runs, so workflows cannot report the branch in notifications (e.g. a Slack job). The same expression renders the branch correctly on dashboard-triggered runs.

Separately: --ref appears undocumented

It is absent from the workflows guides (syntax, get-started, control-flow, automating-eas-cli) and appears only in eas workflow:run --help and the CLI README.