-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fetch-tags: true doesn't actually fetch any tags #1471
Comments
Up, it would be nice to address this. |
This is so annoying and confusing. I set |
Reporting here because I spent a few days trying to figure out why my project's release workflow was failing due to the wheels having the wrong version number. After some digging, it turned out that this change was the cause of this failure since |
Can confirm its still broken...
- name: Checkout
uses: actions/checkout@v4
- name: Fetch tags
run: git fetch --prune --unshallow --tags |
Another possible option is to use filters: - uses: actions/checkout@v3
with:
fetch-depth: 0
filter: tree:0 See #1396. |
Please note that So it is true that your solution works, it is not better but more worldly than just using this:
|
Workaround for actions/checkout#1471
Is this resolved? |
After #579 was merged and released with v3.6.0, the
fetch-tags
option was introduced and it's kind of a breaking change for projects that depend on reading tags from the git history. It sets--no-tags
in thegit fetch
command run by this action. I think this new option should have defaulted totrue
or introduced in v4 instead where it could possibly have had the defaultfalse
.Nevertheless, using
fetch-tags: true
without overriding the defaultfetch-depth: 1
actually doesn't fetch any tags unless the workflow was triggered by a tag push. So I think it's misleading and should be changed to fetch all tags iffetch-tags
is set totrue
. The change to thegit fetch
command run by this action would be to append'+refs/tags/*:refs/tags/*'
(tagsRefSpec
) to the end even thoughfetch-depth
is> 0
.Related issue: #1467
A possible workaround would be to run another
git fetch
after using this checkout action like in #579 (comment), but that feels hacky.Seems the author of the #579 PR also discussed supporting my use-case here: #579 (comment)
I'm sure that this added functionality would be very appreciated. Thanks for your consideration!
The text was updated successfully, but these errors were encountered: