is_default_branch global expression #192
Conversation
crazy-max
force-pushed
the
default-branch
branch
4 times, most recently
from
8378d57 to
51a7c3a
Compare
crazy-max
force-pushed
the
default-branch
branch
from
51a7c3a to
e6b6f70
Compare
| ```yaml | ||
| tags: | | ||
| type=raw,value=latest,enable=${{ github.ref == format('refs/heads/{0}', github.event.repository.default_branch) }} | ||
| # set latest tag for master branch | ||
| type=raw,value=latest,enable=${{ github.ref == format('refs/heads/{0}', 'master') }} | ||
| ``` |
There was a problem hiding this comment.
IMO you should remove this entirely. A solution which may not work under some circumstances should not be suggested, especially without warnings.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Oh, right. I didn't notice.
| | `pull_request` | `refs/pull/2/merge` | `master` | | ||
| | `push` | `refs/heads/master` | | | ||
| | `push` | `refs/heads/my/branch` | | | ||
| | `push tag` | `refs/tags/v1.2.3` | `master` | |
There was a problem hiding this comment.
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-tagsAnd the result is:
$ git checkout master
$ git tag v1.2.3-master
$ git push origin v1.2.3-masterResults in:
https://github.com/felipecrs/ghaction-dump-context/runs/6104557753?check_suite_focus=true#step:3:356
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Very interesting. Thank you.
There was a problem hiding this comment.
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.
This was created with:
$ git checkout master
$ git tag v1.2.3-sentfrommaster
$ git push origin v1.2.3-sentfrommasterAnd 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.
There was a problem hiding this comment.
I would say it's GitHub' side bug:
v1.2.3-sentfromfeaturelooks good: https://github.com/felipecrs/ghaction-dump-context/actions/runs/2222486218 and tagged against32b85ec283cee8ce1a03419b190eab50a1be874drevision.- You then create another tag
v1.2.3-sentfrommasteragainst 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?
There was a problem hiding this comment.
Wow, that would make sense. Let me try again.
There was a problem hiding this comment.
Yep no tag event in your workflow for this commit: https://github.com/felipecrs/ghaction-dump-context/blob/4cf159ecaf43bd0f2487e3fb8f5fc723fce1d32c/.github/workflows/ci.yml
There was a problem hiding this comment.
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 branchrefs/heads/<branch>will always get precedence overrefs/tags/<oldtag>since it's alphabetically ordered- That also explains why
refs/heads/featureis always chosen instead ofmaster, no matter what.
There was a problem hiding this comment.
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):
There was a problem hiding this comment.
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.
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
crazy-max
force-pushed
the
default-branch
branch
from
e6b6f70 to
c2905fb
Compare
fixes #184
Signed-off-by: CrazyMax [email protected]