Feature request: explicit fetch-depth:0 to also fetch tags

[jasonkarns]

v2 is great! It's much faster and optimized for most "main" scenarios of running tests or builds on the latest commit.

However, on tag events, a very common workflow is to publish the tag as a release somewhere (homebrew, npm, github releases, etc). A major component of most release flows is generating release notes which requires knowledge of prior tags.

Using v2, I expected fetch-depth:0 to make this possible.

Problematic run: https://github.com/nodenv/nodenv/runs/549286319?check_suite_focus=true

Error:

Run script/release-notes | tee relnotes.txt
fatal: No tags can describe '443076f046e3db1820d725f6d82947c55dcbdc8f'.
Try --always, or create some tags.

workflow:

    steps:
      - uses: actions/checkout@v2
        with: { fetch-depth: 0 }
      - run: script/release-notes | tee relnotes.txt

My hope is that when fetch-depth:0 is supplied (which implies we want all history) that tags will be fetched as well. I believe this would keep the non-tag "main" scenario fast as desired; while also making the most common tagging scenario more intuitive.

related to #100

[ericsciple]

Also related to #155 - would be good to +1 that PR to help prioritize

[ericsciple]

note, fetch-depth: 0 is currently MAX history but still just for the one ref.

[gitfool]

Nice idea which would mirror GitLab GIT_DEPTH behavior:

To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time, keep the value empty or set to 0.

That said, #155 would be more flexible.

[beatngu13]

This would also be useful when static code analysis tools such as SonarCloud are being used, which often require history for git blame (see Travis docs for comparison). With a depth parameter, one could avoid the extra step for git fetch --prune --unshallow.

Overlooked fetch-depth with fetch-refs …

[jasonkarns]

That said, #155 would be more flexible.

Agree. I'm waffling on whether this feature would still even make sense if #155 were implemented.
I kind of think it would still be worthwhile for scenarios where I user's don't actually need all branch and tag refs, but only those reachable from current ref.

However, I could also see it leading to user confusion. I'll close this for now unless the maintainers consider this separately valuable.

[ejsmith]

Why close this?? There needs to be a simple built in way without having to run separate commands to get full history with tags. #217