branch name of HEAD appears

[paulirish]

was developing on a git branch branch/new-branch. Yes just like that :)

Uploaded some data to canary server here https://github.com/exterkamp/lighthouse-ci-action/commit/21869d5a3234f0d69d8a30027f4455c8057669e5/checks?check_suite_id=299822077

but you can see it was identified as branch HEAD
https://lhci-canary.herokuapp.com/app/projects/3e1ad4e7-689b-4340-83f4-409c84308f89

i notice something weird about this checkout and git branch is odd.. and rev-parse doesnt seem to like it.

---

i guess the currentBranch command just isn't getting it due to the clone/checkout style?? dunno.

but i tried the git command that is used in my bash/fish prompt and it succeeds

git symbolic-ref --quiet --short HEAD 2> /dev/null || \
git describe --all --exact-match HEAD 2> /dev/null || \
git rev-parse --short HEAD 2> /dev/null || \
echo '(unknown)')

in my bash prompt it uses that terrible thing and then seds out 's|^refs/heads/||' but i guess it could do the same with remotes/origin/? :)

anyway GIT IS GREAT! amirite

cc @exterkamp

[patrickhulce]

interesting find! yeah this goes along with the set of fallback commands from #42 (comment)

afaik, this should work as-is already if this script hadn't force checked out a specific hash after checking out the branch. from my understanding of git, force checking out a hash is an explicit attempt to say "I want to be detached from any branch", so reidentifying this hash as the same hash as the HEAD of a branch is a bit of a cheat against the intention of the current git state from my perspective.

I think my preferred solution here would be to throw an error (and do the same in the healthcheck) if the branch comes back as HEAD. Is there a common situation where the setup dictates a clone/checkout approach like this that merits supporting?

[paulirish]

from my understanding of git, force checking out a hash is an explicit attempt to say "I want to be detached from any branch",

yeah that does make sense.

Is there a common situation where the setup dictates a clone/checkout approach like this that merits supporting?

you can see it in the checkout action of https://github.com/exterkamp/lighthouse-ci-action/commit/21869d5a3234f0d69d8a30027f4455c8057669e5/checks?check_suite_id=299822077

we looked and there doesn't appear to be much configurability around this.

another option would be to use one of these
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/using-environment-variables#default-environment-variables

[patrickhulce]

Sweet yeah let's just use GITHUB_HEAD_REF if it's available like we do for travis then and error if we can't determine it otherwise 👍