Skip to content

fix(ci): send real branch and PR for CI scans - #1475

Open
John-David Dalton (jdalton) wants to merge 1 commit into
v1.xfrom
jdalton/surf634-v1x-backport
Open

fix(ci): send real branch and PR for CI scans#1475
John-David Dalton (jdalton) wants to merge 1 commit into
v1.xfrom
jdalton/surf634-v1x-backport

Conversation

@jdalton

@jdalton John-David Dalton (jdalton) commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator

LLM Description written by Claude Code:claude-opus-5

Actions needed

  • Merge this, then cut a v1.x release. This is the backport that unblocks Netflix, and they run the published latest dist-tag (v1.1.152, on v1.x), so nothing changes for them until a release ships.
  • Nothing to port to main. Both fixes are already there with tests.

What was broken

Scans from socket ci in GitHub Actions did not show up in either the Main or the PR tab of the dashboard. Two separate causes, both already fixed on main (SURF-634), neither on v1.x:

  1. actions/checkout leaves HEAD detached, which is the normal state in CI. gitBranch handled that by falling back to a short commit SHA, and a SHA can never match the repo default branch, so the scan was not a main-branch scan. On a pull request it was not a PR scan either.
  2. socket ci hardcoded pullRequest: 0, so a scan from a pull_request event could not land in the PR tab even with the branch right.

The fix

getCiBranch() in src/utils/git.mts reads the branch the workflow says it is on before falling back to the SHA: GITHUB_HEAD_REF first (the pull request head branch), then GITHUB_REF_NAME when GITHUB_REF_TYPE is branch. GITHUB_HEAD_REF has to win, because on a pull_request event GITHUB_REF_NAME is <pr_number>/merge, which is not a branch name.

detectCiPullRequestNumber() in src/commands/ci/handle-ci.mts pulls the number out of GITHUB_REF, which is refs/pull/<n>/merge on those events. Outside a pull request it returns 0 and the API request omits pull_request as before.

Port notes and test results

main is a monorepo and keeps this logic in packages/cli/src/util/git/git-remote-info.mts. v1.x is the old flat tree, so no files were copied. The branch logic went into the existing src/utils/git.mts, next to getBaseBranch, and the pull request logic into the existing handle-ci.mts.

main reads the environment through getGithubRefName() / getGithubRefType() helpers that do not exist on v1.x. Here the values are read straight from process.env with envAsString, because neither GITHUB_HEAD_REF nor GITHUB_REF is part of the frozen constants.ENV snapshot that getBaseBranch uses.

16 new tests, all passing, no mocks. getCiBranch is covered directly; gitBranch is covered against a real temporary git repo that gets detached with git checkout --detach, so the detached-HEAD path is the real thing rather than a stub. The tests clear GITHUB_HEAD_REF, GITHUB_REF_NAME, GITHUB_REF_TYPE, and GITHUB_REF first, otherwise they would silently read the values of the CI job they run inside.

Checked that the tests are not vacuous. Disabling the branch preference in git.mts fails exactly the two detached-HEAD CI tests, and both report the commit SHA (expected 'b3833ac' to be 'feature/pr-branch') that is the bug customers see. Making detectCiPullRequestNumber always return 0 fails exactly the two refs/pull/<n>/... tests. Everything else stayed green in both runs, and both breaks were reverted.

tsgo --noEmit and eslint are clean.

Not in this PR

make_default_branch still defaults to false here, same as on main. Flipping it would make every CI run establish the server-side default branch for every customer, which is an open product question tracked on SURF-634, so it stays as-is.


Note

Low Risk
Scoped to CI metadata for scan creation; no auth or API contract changes beyond sending correct branch/PR fields that were previously wrong or omitted.

Overview
Fixes GitHub Actions socket ci scans missing from the dashboard Main and PR tabs by labeling scans with the workflow’s real branch and PR number instead of a detached-HEAD commit SHA and hardcoded pullRequest: 0.

Branch detection: Adds getCiBranch() to read GITHUB_HEAD_REF (PR head) or GITHUB_REF_NAME when GITHUB_REF_TYPE is branch, and wires gitBranch() to use it before falling back to a short SHA in detached HEAD (typical actions/checkout).

PR number: Adds detectCiPullRequestNumber() to parse GITHUB_REF (refs/pull/<n>/merge or head) and passes that into handleCreateNewScan instead of always 0.

Adds vitest coverage for both helpers and for gitBranch in detached HEAD with CI env vars cleared.

Reviewed by Cursor Bugbot for commit fc93cb1. Configure here.

Backport of the SURF-634 fix from main. In a CI checkout HEAD is
detached, so gitBranch fell through to a short commit SHA. A SHA can
never match the repo's default branch, so those scans never showed up
in the Main or PR tabs of the dashboard. Prefer the branch the
workflow says it is on: GITHUB_HEAD_REF for a pull request, else
GITHUB_REF_NAME when GITHUB_REF_TYPE is branch, and only then the SHA.

socket ci also hardcoded pullRequest to 0, so a scan from a
pull_request event could not land in the PR tab either. Derive the
number from GITHUB_REF, which is refs/pull/<n>/merge on those events.

main carries the branch logic in
packages/cli/src/util/git/git-remote-info.mts. v1.x is the flat tree,
so it lands in src/utils/git.mts as getCiBranch, and the environment
is read straight from process.env because GITHUB_HEAD_REF and
GITHUB_REF are not part of the constants.ENV snapshot.

make_default_branch is untouched and still defaults to false.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant