Name PR build artifacts after the branch, not a merge sha - #23
Merged
Conversation
Actions checks a pull request out detached at a merge commit it invents, so git symbolic-ref finds nothing and BUILD_BRANCH fell through to rev-parse. Every artifact from a PR was therefore named after a sha that exists on no branch and cannot be found in local history - with several PRs open at once they are a row of identically shaped names none of which say what they are. Take the branch from the environment when CI tells us what it is. GITHUB_HEAD_REF is the source branch of a pull request; GITHUB_REF_NAME is the branch of a push, and on a pull request it is "<number>/merge", which is why it cannot be checked first. Falls back to the old behaviour when neither is set, so building locally is unchanged. Also widens the sanitiser from slashes to anything a filename should not carry, since git allows a few more of those than it looks. A push to main still produces no branch suffix, so release names do not move. pull_request GITHUB_HEAD_REF=feat/favorites NextUI-20260812-feat-favorites-0 push main GITHUB_REF_NAME=main NextUI-20260812-0 local (no CI env) NextUI-20260812-<branch>-0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Independent of the feature stack — based on
mainso it can merge first and make the rest of the stack testable.The problem
Actions checks a pull request out detached at a merge commit it invents, so
git symbolic-reffinds nothing andBUILD_BRANCH(makefile:21) fell through togit rev-parse --short HEAD. Every PR artifact was named after a sha that exists on no branch and can't be found in local history.Concretely, PR #1's build came out as:
f4b9488is not the head offeat/favorites(0d0cb4e) — it's GitHub's synthetic merge commit. With six PRs open, that's six 105 MB downloads with interchangeable names and no way to tell them apart.It works correctly on a push to main, which is presumably why it went unnoticed.
The fix
Take the branch from the environment when CI tells us what it is:
GITHUB_HEAD_REF— the source branch of a pull request.GITHUB_REF_NAME— the branch of a push. On a pull request this is<number>/merge, which is why it can't be checked first.symbolic-ref/rev-parsechain when neither is set, so local builds are unchanged.Also widens the sanitiser from
/to anything a filename shouldn't carry, since git permits a few more of those than it looks.Verified
make nameunder each trigger:GITHUB_HEAD_REF=feat/favorites,GITHUB_REF_NAME=1/mergeNextUI-20260812-feat-favorites-0GITHUB_HEAD_REF=fix/search-index-capNextUI-20260812-fix-search-index-cap-0GITHUB_REF_NAME=mainNextUI-20260812-0GITHUB_REF_NAME=fix/atomic-writesNextUI-20260812-fix-atomic-writes-0NextUI-20260812-fix-ci-artifact-names-0GITHUB_HEAD_REF=feat/wip~2 oddNextUI-20260812-feat-wip-2-odd-0A push to main still produces no branch suffix, so release naming does not move.
Getting it onto the open PRs
CI builds the merge commit, so a PR only picks this up once the fix is in its base branch:
main— merge this, re-run their CI, and their artifacts are named.mainfirst.Not fixed here
BUILD_HASH(makefile:20) has the same origin and still records the merge sha inversion.txt. That one is arguably correct — it identifies the exact tree that was built — but it does mean the hash on a PR build won't match anything in your branch. Left alone rather than widened into this change.