Hitting a weird bug where distance to last tag is far away about poetry-dynamic-versioning HOT 3 CLOSED

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

from poetry-dynamic-versioning.

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.

from poetry-dynamic-versioning.

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.

from poetry-dynamic-versioning.