Add option to fetch tags even if fetch-depth > 0

[RobertWieczoreck]

Hi there!

This PR adds an optional fetch-tags option that can be used to override the default behavior of adding the --no-tags arg to the generated git fetch command if fetch-depth is configured and not 0.

This way, users can use fetch-depth while still getting the tags inside this range, which can e.g. be important when using automatic GIT versioning plugins like jgitver.

Tested using a workflow in a separate branch that verifies function as well as backwards compatibility: See Run 4255310531.

All Checks are green.

Also see PR 2 in my fork (description is mostly copied from there).

Fixes #448

[RobertWieczoreck]

Hello @thboop, @ericsciple, I don't really know what flow to follow for contributions and didn't find any guidelines (and it's my first one on GitHub..). Could you please have a look and tell me how to get this reviewed and merged "correctly"? :) Thanks in advance

[miluoshi]

Any updates on this? It looks like there are merge conflicts in this PR.

[RobertWieczoreck]

Any updates on this? It looks like there are merge conflicts in this PR.

The maintainers don't seem to notice this PR, as they need to approve the workflow runs (and maybe review it). I don't know if I did something wrong as it's my first contribution on GitHub.

Regarding he merge conflicts: I just had to fetch the latest changes from main to my fork. The updated fork PR is #2. Still all checks green. Also testet again with a workflow in a separate branch: 4255310531 Still works.

I have another contribution in mind regarding the new GIT sparse index, which yields extreme performance gains when working with large monorepos. I may just publish my fork at some point if no reaction occurs here - already using it internally right from the fork branch.

[miluoshi]

@RobertWieczoreck thanks for your contribution! Hopefully one of maintainers notices the PR.

I have another contribution in mind regarding the new GIT sparse index, which yields extreme performance gains when working with large monorepos.

I am curious about your contribution that uses git sparse index. I am working with a monorepo that would need some performance improvements in checkout process. Can you share any details?

[bonomat]

It would be cool if we could get this feature in. In our build process we want to include the latest git tags but at the moment this github action does not allow us to fetch them.

[RobertWieczoreck]

@miluoshi

I am curious about your contribution that uses git sparse index. I am working with a monorepo that would need some performance improvements in checkout process. Can you share any details?

I didn't have time to analyse the changes required to this action completely, but it would be a bigger change than this PR, as right now even a regular sparse-checkout isn't possible. So we would need at least:

1. A new option called sparse-checkout (or sparse-directories?) with default false that...
2. Triggers the sparse-checkout init (smth. like adding --cone --sparse-index to the git init command?) and ...
3. Accepts a list of directories to be used for a git sparse-checkout set command prior to checkout
4. Another option use-sparse-index (default true), as some users might want to disable it due to compatibility issues with external tools that read the index

Notes:

• The exact commands needed could depend on the version of GIT used (already detected)
• The sparse-index feature is available from GIT 2.34 only

I need to perform some local tests on how to best integrate the feature with the current commands the action issues (without breaking other use-cases) and with the commands available in different GIT versions.

I hope to be able to start working on this before the end of the year.

Update: I did not manage to work on this, but there is another PR now implementing this: #680

@bonomat and others in need of this feature: You can already use it directly from my repository if you want. The company I work for already does so.

- name: Checkout with fetch-depth=50 and fetch-tags=true
    uses: RobertWieczoreck/checkout@b9d6ac43b8b251913ae7710900b7e6c29b6f52e3
    with:
      fetch-depth: 50
      fetch-tags: true

This way you'll get exactly the changes of this PR (more secure), but miss updates from this main repo. If you want to use the latest version of the branch (I try to keep it updated to the main repository when it changes), you could use RobertWieczoreck/checkout@add-fetch-tags-option.

@thboop, @ericsciple: I still hope you'll find some time to review this PR / approve the workflow runs, so I try it with another mention :)

[EwoutH]

Any updates on this PR? I would love to be able to fetch tags without fetching the full repo's history!

[anthony-steele-cko]

Any update on this? I would very much like this option to fetch tags without fetching the full repo's history.

[tiagovrtr]

This would be a great addition. looking forward to it

[derN3rd]

Sad to see, that there are so many good PRs that are not used/merged by the Github staff...

[markstijnman-shell]

Hope this gets picked up soon as well, would solve at least 3 issues from the looks of it: #338, #448, and #701.

[RobertWieczoreck]

I updated the branch once again and still hope to get some feedback from the maintainers.

[dlwiii]

The RobertWieczoreck fix solves the issue for us. But it sure would be nice to be able to get tags using the standard checkout

[prashant-shahi]

any update on this?

[RobertWieczoreck]

I rebased the branch to the lastest changes from main (once again..).

- name: Checkout with fetch-depth=50 and fetch-tags=true
  uses: RobertWieczoreck/checkout@add-fetch-tags-option
  with:
    fetch-depth: 50
    fetch-tags: true

At this point I would recommend to just use my fork branch in your workflows, as I have no hope left to get feedback from the maintainers. If anyone needs tags (maybe based on specific tags from here), just PM me or request it here. Also don't hesitate to post me a message if the branch lags some important changes from here, as I only check this every month or so.

[RobertWieczoreck]

Thanks a lot for your approval, @nikimahurin-RL :)

Could you also approve the workflow runs? This is required because this is my first public GitHub contribution :/

[keenan-v1]

Why isn't this merged yet?

[gbpoole]

+1

Would be great if this could be actioned soon.

[kduret]

Hi @vmjoseph @vanZeben @rentziass

Sorry to ping you, but is it possible you review this pull request ?

Because it seems many people want this enhancement :)

[RobertWieczoreck]

Looks good. Can someone please merge it?

@ventsyv: Thanks for your review - I updated (rebased) the fork branch again to get rid of merge conflicts.

But still someone (a maintainer) has to approve the workflow runs :(

[php-coder]

It would be great to see it merged!

@TingluoHuang could you, please, take a look? Or ping someone who can? Thanks!

[kduret]

This PR is definitely ignored by maintainers :disappointed:

[coolcalcacol]

@fhammerl can you take a look please?

[jmgilman]

This has 82 thumbs up reactions. Why is it being ignored?

[kduret]

@RobertWieczoreck try to close this PR and open a new one :smirk: This will put it at the top of the listing Maybe maintainers will take a look... :eyes:

[ljharb]

@kduret all that will do is add more notifications to the pile that maintainers are obviously ignoring. Try filing a support ticket or something maybe, but don't create github noise.

[kduret]

@ljharb already contacted the support... and this is the answer :

You could reach out to any of the contributors. They should be able to take a look. I can see there are a number of pull requests open and I'm sure there are reviewers going through them.

[ljharb]

Then the best bet is to wait, even if it takes a decade.

[luketomlinson]

Hi @RobertWieczoreck, thanks for this PR. I think this is a valuable change, but I would ask that you could add a test for this? I am thinking it might make sense to break out building the args array inside of the fetch method and test that the args array looks correct with and without your new option? Once we have that test, I think it is reasonable to get this merged.

[pawamoy]

Do I understand this PR correctly if I say that the following will fetch the last commit but also all tags:

    - name: Checkout
      uses: actions/checkout@v3
      with:
        fetch-tags: true

Or does this change only apply when fetch-depth is greater than 0? :thinking:

My use-case: I run a tool in CI that detects API breaking changes (Python). By default it compares HEAD to the latest tag. It means I currently have to set fetch-depth: 0, but I don't need the whole history, only the tags / tagged commits. Not even sure if what I am asking for is possible :thinking:

UPDATE: sorry for the noise on this PR, I was able to make it work with the following additional step:

    - name: Fetch all tags
      run: git fetch --depth=1 --tags

...and by updating my tool to run git tag -l --sort=-committerdate | head -n1 instead of git describe --tags --abbrev=0 which fails on sparse history.