Hitting a weird bug where distance to last tag is far away

[fredrikaverpil]

Hi!

I'm hitting a weird bug, I think...

In a GitLab PR, the commit distance is quite far away from the last tag. I've noticed that all of a sudden, I'm getting a 0.0.1 release when building a wheel.

Full output to illustrate the problem:

$ git log --graph --decorate --pretty=oneline --abbrev-commit
* cf46f54 (HEAD -> somebranch, origin/somebranch) obfuscated
* 0513694 obfuscated
* 9925bf0 obfuscated
* c8de772 obfuscated
* d0c594f obfuscated
* 4c28f28 obfuscated
* 7bddeb2 obfuscated
* d53f67c obfuscated
* c761777 obfuscated
* dc19807 obfuscated
* dc17e6b obfuscated
* bc8d09a obfuscated
* de08edb obfuscated
* 4251f56 obfuscated
* db35304 obfuscated
* d0561a1 obfuscated
* fd8dded obfuscated
* 9a98dca obfuscated
* b02bf94 obfuscated
* 687c86b obfuscated
* 8ee81d9 obfuscated
* 22cb5d8 obfuscated
* 99ddcda obfuscated
* 53881f6 obfuscated
* f71452b obfuscated
* ab06b3b obfuscated
* fd6e0ed obfuscated
* e4d44d4 obfuscated
*   0b2714e Merge branch 'somebranch' of xxx into somebranch
|\  
| * ec62f49 obfuscated
| * 29309df obfuscated
| * c1e8ed4 obfuscated
| * c681b20 obfuscated
| * 86e0550 obfuscated
| * e7586b0 obfuscated
| * 98e0b38 obfuscated
| * 1041e4d obfuscated
| * f083c0b obfuscated
| * 8d94c54 obfuscated
| * 5d3deb3 obfuscated
| * 612d12f obfuscated
| * 49ef012 obfuscated
| * 5288f58 obfuscated
| * cad651d obfuscated
| * e4102f4 obfuscated
| * 3f7fdc6 obfuscated
| * 600b579 obfuscated
| * e2cf989 obfuscated
| * fc52824 obfuscated
| * 014cd27 obfuscated
| * d379221 obfuscated
| * 3ae644f obfuscated
| * 8b74674 obfuscated
| * 5318a9a obfuscated
| * 93318a5 obfuscated
| * 5f2dfa0 obfuscated
| * 3fea383 obfuscated
| * 1fe44c3 obfuscated
| * 5270882 obfuscated
| * 9b0f7da obfuscated
| * 5271bcd obfuscated
| * 2a7a988 obfuscated
| * b698566 (tag: multitag-bug-test, tag: 1.68.0, origin/master, origin/HEAD, master) obfuscated

$ git --no-pager tag
0.1.0
1.0.0
1.1.0
1.10.0
1.11.0
1.12.0
1.16.0
1.17.0
1.18.0
1.19.0
1.2.0
1.20.0
1.21.0
1.22.0
1.23.0
1.24.0
1.24.1
1.24.2
1.25.0
1.26.0
1.27.0
1.28.0
1.29.0
1.3.0
1.30.0
1.31.0
1.32.0
1.33.0
1.34.0
1.35.0
1.36.0
1.37.0
1.38.0
1.38.1
1.39.0
1.4.0
1.4.1
1.40.0
1.41.0
1.42.0
1.43.0
1.44.0
1.45.0
1.46.0
1.47.0
1.48.0
1.49.0
1.5.0
1.5.1
1.5.2
1.5.3
1.50.0
1.51.0
1.52.0
1.53.0
1.54.0
1.55.0
1.56.0
1.57.0
1.58.0
1.59.0
1.6.0
1.60.0
1.61.0
1.62.0
1.63.0
1.64.0
1.65.0
1.66.0
1.67.0
1.68.0
1.7.0
1.7.1
1.7.2
1.8.0
1.8.1
1.9.0
1.9.1
1.9.2

$ poetry build --format wheel
Building pc-swdp-generic (0.0.1.dev90+gcf46f54.d20210618082223)
  - Building wheel
  - Built pc_swdp_generic-0.0.1.dev90+gcf46f54.d20210618082223-py3-none-any.whl

A couple of commits back, in the very same PR I see this when I build the wheel:

$ poetry build --format wheel
Building pc-swdp-generic (1.66.1.dev32+gddc29e5.d20210611144222)
  - Building wheel
  - Built pc_swdp_generic-1.66.1.dev32+gddc29e5.d20210611144222-py3-none-any.whl

Have you seen anything like this before?

[mtkennerly]

That's very strange, considering that 0.0.1 isn't even in your tag list and that Dunamai's placeholder is 0.0.0. Some questions:

• What are your plugin settings in pyproject.toml?
• I'm not familiar with GitLab, but could there have been a change (either specific to your project or generally on their service) to clone the repo without tags?
• Is that git --no-pager tag output from your local computer or from the GitLab workflow? If it's not from GitLab directly, I think it would be good to add it to the workflow and see how it compares. You could also add in dunamai from git --debug.

[fredrikaverpil]

We noticed something super strange, and it was that with a great distance from the last tag, git tag would return fewer and fewer tags. This would continue with each commit in that GitLab PR until git tag no longer returned any tags.

Since git tag did not return any tags, it's natural that we'd get the starting 0.0.1 (as if no tags existed).

I think we can close this, as we solved it my squashing all commits down into one in that PR. This took everything back to normal. I'm thinking there could be a bug in gitlab perhaps. I should write a script that loops through creating batches of 20 or so git tags. And then see when GitLab starts to act up.

I will close this, as I don't think it's related to poetry-dynamic-versioning.

[fredrikaverpil]

Hi, I finally found out what was causing this and figured I'd report back here for completeness;

In GitLab, the git repo is cloned down with a "depth" of 50. This means that after 50 commits in a pull requests, neither setuptools_scm or poetry-dynamic-versioning will find the last git tag (which is at a distance of 50). Here, the SCM-driven semver resets into 0.0.1+dev50.

To fix this, you can set a GitLab CI/CD variable GIT_DEPTH to 0 to make GitLab clone down the entire repo, all branches and without any "depth" limit. Or you can set a maximum of 1000. The docs on this can be found here: https://docs.gitlab.com/ee/ci/pipelines/settings.html#git-shallow-clone