feat: Make `cz bump` work on shallow clones

[robertschweizer]

Description

Try to git fetch missing tags if working on a shallow clone.

This allows reliably setting up your CI to only fetch the latest changes. E.g. Gitlab CI uses shallow clones with a depth of 20 by default: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77576

Only tag_exists() had to be modified to make this work for cz bump. Other functions are not ready yet, more functions would have to include a git fetch for that. There are also other problems still with Gitlab CI's shallow clones, e.g. https://github.com/commitizen-tools/commitizen/issues/593. But for my use-case of just running cz bump and cz check in Gitlab CI this works nicely.

Checklist

• [x] Add test cases to all the changes you introduce
• [x] Run ./scripts/format and ./scripts/test locally to ensure this change passes linter check and test
• [x] Test the changes on the local machine manually
• [ ] Update the documentation for the changes -> The printed warning makes this unnecessary.

Additional context

I was worried about slowing down error reporting in non-CI workflows ("git fetch" calls can sometimes take a while if your connection is bad). To minimize the risk for this, I'm now only fetching the tag for shallow clones and always printing a warning when this happens.

I was hit by this issue while trying out Commitizen in Gitlab CI on a monorepo, where some packages haven't seen a release for >50 commits. It's also large enough for the shallow clone to really make sense in the CI.

[codecov[bot]]

Codecov Report

Base: 97.92% // Head: 98.10% // Increases project coverage by +0.18% :tada:

Coverage data is based on head (416f68c) compared to base (db42a95). Patch coverage: 89.18% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #649      +/-   ##
==========================================
+ Coverage   97.92%   98.10%   +0.18%     
==========================================
  Files          35       39       +4     
  Lines        1252     1690     +438     
==========================================
+ Hits         1226     1658     +432     
- Misses         26       32       +6     

Flag	Coverage Δ
unittests	98.10% <89.18%> (+0.18%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
commitizen/commands/init.py	87.93% <84.00%> (-3.74%)	:arrow_down:
commitizen/__version__.py	100.00% <100.00%> (ø)
commitizen/commands/changelog.py	98.86% <100.00%> (ø)
commitizen/commands/check.py	100.00% <100.00%> (ø)
commitizen/exceptions.py	100.00% <100.00%> (ø)
commitizen/git.py	98.66% <100.00%> (+0.07%)	:arrow_up:
commitizen/bump.py	100.00% <0.00%> (ø)
commitizen/__init__.py	100.00% <0.00%> (ø)
commitizen/changelog.py	100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[robertschweizer]

It doesn't look like the CI tests failed because of my change. Please let me know if that's the case in your opinion.

[Lee-W]

@robertschweizer I just reran the CI and it passed. Will take a deeper look. Thanks!

[robertschweizer]

Thanks a lot for your review and feedback! I'm sorry about this, but I actually don't need this change anymore.

In our fork we actually restrict git log output to the CWD (.) to run commitizen on monorepo folders. It turns out filtering logs by directory does not work with shallow clones unless you unshallow the complete history up to the reference tag. Combine that with Gitlab's unstable behavior when doing a lot of unshallowing made us go back to using full clones for this CI job.

Feel free to close this MR unless someone else finds it useful.