Right now git fetch is executed with --no-tags by default and there is no option available to change this. It would be particularly useful (especially for tag based versioning) to support a tags: true property on this action which removes the --no-tags flag from the fetch operation.
You can do that with the ref input.
I have tried ref and it still uses --no-tags when fetching.
Specifically I use:
- uses: actions/checkout@v1
with:
repository: graalvm/mx.git
ref: 5.194.3
path: $GITHUB_WORKSPACE/mx
And the result is:
...
git -c http.extraheader="AUTHORIZATION: basic ***" fetch --no-tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/*
...
git checkout --progress --force 5.194.3
##[error]error: pathspec '5.194.3' did not match any file(s) known to git
@zakkak try refs/tags/5.194.3, what's the runner version you have?

Using refs/tags/5.194.3 did the trick (It would be nice to support 5.194.3 as well, I guess it might be ambiguous though).
Thank you!
Current runner version: '2.157.3'
Apparently the runner release process has some setting problem, you should get 2.157.5 now which should allow you just do:
- uses: actions/checkout@v1
with:
ref: 5.194.3
We suppose to fetch all tags in checkout@V1, so ref: 5.194.3 should be good enough.
@zakkak thanks for bringing this up so I can realize the setting problem. 馃檱
@TingluoHuang what happens if I have both a branch and a tag with the same name?
I think the branch get highest priority right? This could be pretty confusing and hard to debug.
Yes, the branch gets preferred, the output will give you some hints. :)
git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
Thanks folks, I am aware of the ref option however that's not specifically what I'm looking for. Let me see if I can provide a bit more context as to what we're doing:
We derive version numbers for our applications and libraries using their git tag history. This information is gathered using a combination of git describe --tags --first-parent and git rev-parse --short HEAD. For the former to work correctly, we need to have the collection of tags available in our local repo - however when using --no-tags this is obviously not the case.
In our specific use case, explicitly fetching a single tag using the ref option does not provide what we're looking for since we do not know ahead of time which tag it is that we're interested in for the purpose of git describe.
I think the command runs with --tags now, so I guess this issue can be closed.