Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

is_default_branch global expression #192

Merged
merged 4 commits into from Apr 25, 2022

Conversation

crazy-max
Copy link
Member

@crazy-max crazy-max commented Apr 20, 2022

fixes #184

Signed-off-by: CrazyMax crazy-max@users.noreply.github.com

```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') }}
```
Copy link
Contributor

@felipecrs felipecrs Apr 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@crazy-max crazy-max Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@felipecrs felipecrs Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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` |
Copy link
Contributor

@felipecrs felipecrs Apr 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@crazy-max crazy-max Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

"base_ref": "refs/heads/master",

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

Copy link
Contributor

@felipecrs felipecrs Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very interesting. Thank you.

Copy link
Contributor

@felipecrs felipecrs Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@crazy-max crazy-max Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it's GitHub' side bug:

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?

Copy link
Contributor

@felipecrs felipecrs Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@crazy-max crazy-max Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@felipecrs felipecrs Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@felipecrs felipecrs Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@crazy-max crazy-max Apr 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@crazy-max crazy-max marked this pull request as ready for review Apr 22, 2022
crazy-max added 4 commits Apr 25, 2022
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
@crazy-max crazy-max merged commit 0978a06 into docker:master Apr 25, 2022
19 checks passed
@crazy-max crazy-max deleted the default-branch branch Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The suggested default branch example does not work for schedule
2 participants