The sandbox's copy-report action exists to tell a triager which build produced a problem. On every deployed sandbox it names a branch that does not exist, so that line points nowhere.
Impact
buildReport assembles the block a reporter pastes into an issue:
## Video.js sandbox preview
- URL: …
- Version: …
- Build: master @ db1d097
- Selection: …
master is not a branch of this repository — the default branch is main. Anyone acting on a pasted report has to know to ignore that field.
The commit is unaffected and always correct, so a report is still traceable; the branch is the part that misleads. Local runs are unaffected, which is why it does not show up in development.
Reproduction
- Open any deployed sandbox — production at https://v10-sandbox-git-main-mux.vercel.app or a PR preview.
- Copy the preview report from the toolbar.
- The
- Build: line reads master @ <commit>.
Observed on production at commit db1d097 (fix(hlsjs-video): route legacy hls mime types to hls.js, #2866), which is a real ancestor of main. git ls-remote --heads origin master returns nothing.
Cause
apps/sandbox/vite.config.ts reads the branch from the local checkout at build time:
__SANDBOX_BRANCH__: JSON.stringify(describeGit('rev-parse', '--abbrev-ref', 'HEAD')),Vercel's build container checks out the deployed commit but does not preserve the branch name, so rev-parse --abbrev-ref HEAD answers master whatever was deployed. The unknown/HEAD fallbacks in the consumer never fire, because master looks like a real answer.
Resolving it
Vercel's own environment variables name the real branch and commit, with describeGit still covering local builds and checkouts with no git metadata, as on StackBlitz:
__SANDBOX_BRANCH__: JSON.stringify(
process.env.VERCEL_GIT_COMMIT_REF || describeGit('rev-parse', '--abbrev-ref', 'HEAD')
),Verified on a preview deploy: the report changed from master @ … to spike/remotion-media @ ….
VERCEL_GIT_COMMIT_SHA is available for the commit too, but is not needed — describeGit already answers that correctly, since Vercel checks out the real commit.
Acceptance criteria
- A report copied from a deployed sandbox names the branch that was deployed.
- A report copied from a local run still names the local branch.
- A checkout with no git metadata still produces a report rather than failing.
The sandbox's copy-report action exists to tell a triager which build produced a problem. On every deployed sandbox it names a branch that does not exist, so that line points nowhere.
Impact
buildReportassembles the block a reporter pastes into an issue:masteris not a branch of this repository — the default branch ismain. Anyone acting on a pasted report has to know to ignore that field.The commit is unaffected and always correct, so a report is still traceable; the branch is the part that misleads. Local runs are unaffected, which is why it does not show up in development.
Reproduction
- Build:line readsmaster @ <commit>.Observed on production at commit
db1d097(fix(hlsjs-video): route legacy hls mime types to hls.js, #2866), which is a real ancestor ofmain.git ls-remote --heads origin masterreturns nothing.Cause
apps/sandbox/vite.config.tsreads the branch from the local checkout at build time:Vercel's build container checks out the deployed commit but does not preserve the branch name, so
rev-parse --abbrev-ref HEADanswersmasterwhatever was deployed. Theunknown/HEADfallbacks in the consumer never fire, becausemasterlooks like a real answer.Resolving it
Vercel's own environment variables name the real branch and commit, with
describeGitstill covering local builds and checkouts with no git metadata, as on StackBlitz:Verified on a preview deploy: the report changed from
master @ …tospike/remotion-media @ ….VERCEL_GIT_COMMIT_SHAis available for the commit too, but is not needed —describeGitalready answers that correctly, since Vercel checks out the real commit.Acceptance criteria