IMO you should remove this entirely. A solution which may not work under some circumstances should not be suggested, especially without warnings.

I actually updated this example with a hardcoded branch name to show how to handle this case for a specific branch as it seems still valid for me.

Oh, right. I didn't notice.

I believe you should not populate this variable in tag events, because it will always be the default branch.

Tags aren't anyhow tied to a branch in Git.

Example:

$ git checkout -b feature
$ git commit -m "Test commit" --allow-empty
$ git tag v1.2.3
$ git push --follow-tags

And the result is:

https://github.com/felipecrs/ghaction-dump-context/runs/6104549396?check_suite_focus=true#step:3:356

$ git checkout master
$ git tag v1.2.3-master
$ git push origin v1.2.3-master

Results in:
https://github.com/felipecrs/ghaction-dump-context/runs/6104557753?check_suite_focus=true#step:3:356

Agree that a tag points to a commit, and commits exist independently of branches. But GitHub context seems to record the branch where this event occurs:

You can see it in your logs: https://github.com/felipecrs/ghaction-dump-context/runs/6104549396?check_suite_focus=true#step:3:360

Very interesting. Thank you.

BTW, I made both master and feature point to the same revision, and it does not matter how I tag (or push) them, GitHub seems to just select one randomly to be the base_ref in case both matches the same revision.

https://github.com/felipecrs/ghaction-dump-context/runs/6164266775?check_suite_focus=true#step:3:360

This was created with:

$ git checkout master

$ git tag v1.2.3-sentfrommaster

$ git push origin v1.2.3-sentfrommaster

And it shows base_ref as feature.

This is just to say that this information isn't something to be relied on. I don't know if is worth mention this in the documentation or not.

I would say it's GitHub' side bug:

• v1.2.3-sentfromfeature looks good: https://github.com/felipecrs/ghaction-dump-context/actions/runs/2222486218 and tagged against 32b85ec283cee8ce1a03419b190eab50a1be874d revision.
• You then create another tag v1.2.3-sentfrommaster against the very same commit: https://github.com/felipecrs/ghaction-dump-context/actions/runs/2222492052

I suppose GitHub manages a DB that records the base ref of a tag. In this case you have created both tag against the same commit so I presume GitHub logic returns all tags for the same commit and matches the first one he found in the DB and therefore here the wrong ref is returned. Just speculations ofc but that seems to be it.

Maybe they SELECT 1 and ORDER by name or smth like that. Can you try to tag from master for a tag named smth like v1.2.3-aaaaa against the same commit and see what it returns?
Can you also tag against another commit from master?

Wow, that would make sense. Let me try again.

Yep no tag event in your workflow for this commit: https://github.com/felipecrs/ghaction-dump-context/blob/4cf159ecaf43bd0f2487e3fb8f5fc723fce1d32c/.github/workflows/ci.yml

Ok, check my new tags. I believe the base_ref gets populated with the first reference in alphabetical order.

• refs/heads/<branch> will only be there if tags matches the latest revision of the branch
• refs/heads/<branch> will always get precedence over refs/tags/<oldtag> since it's alphabetically ordered
• That also explains why refs/heads/feature is always chosen instead of master, no matter what.

BTW, in case you publish a tag against a revision which does not point to the latest version of a tag neither another tag, here is what you get (null):

https://github.com/felipecrs/ghaction-dump-context/runs/6164973057?check_suite_focus=true#step:3:360

BTW, in case you publish a tag against a revision which does not point to the latest version of a tag neither another tag, here is what you get (null):

Yes just saw that too and I don't like that. I will remove support of base_ref (for push tag events) as it seems to be not what we want.