Non-deterministic abbreviated git commit SHA in dev versions

[pattersam]

Hi 👋

Love this tool 🙂 thanks for developing & maintaining it 🙇

I am using dunamai on a monorepo (inspired by Gerben Oostra's reference implementation ) where a CICD has multiple parallel jobs which each run something along the lines of VERSION=$(poetry run dunamai from any) to set a local version of a python package.

As our monorepo has grown in size, we started noticing some occasional inconsistencies between the dev (post/pre-release) versions dunamai is generating between the different parallel CICD jobs.

In some jobs, the version would look like 1.20.0.post1.dev0+629c74a3 (8 characters of SHA)

while in other jobs, the commit part would be 1 character less like 1.20.0.post1.dev0+629c74a (7 characters of SHA)

and so in a downstream job where we expect all those versions to be identical, it would understanibly fail.

Using --full-commit solves the problem, but of course, isn't quite as nice to have massive SHAs if it could be avoided.

So looking into it, I found this line is where it's coming up with the {commit} part of that dev pep440 version

And reading up on the %h argument of git log which is responsible for returning the abbreviated SHA, I found this thread explaining that the number of characters in the abbreviated SHA is dynamically calculated based on some approximation of the number of objects in the git repo.

To be honest, I would have still expected git to arrive at the same abbreviated SHA across different CI jobs for the same commit. I don't exactly know what differences (ci runner caching?) might be causing it to arrive at a different truncation, but nonetheless it doesn't in practice for our situation 🤷

So my eventual fix was to slap on a git config --global core.abbrev 8 before I use dunamai, but it would be even better if I could just pass that config in as something like a --commit-length 8 argument and am wondering if you would consider something like that as a feature request 🙏

PS: we also considered crafting our own --format with {commit:8} in it, but I'm not a huge fan of manually handcrafting the existing pep440 format you've implemented just to circumvent this problem.

[mtkennerly]

Hi!

it would be even better if I could just pass that config in as something like a --commit-length 8 argument and am wondering if you would consider something like that as a feature request 🙏

Makes sense to me 👍 I'm open to adding that.

[mtkennerly]

This is now available in v1.22.0 :)

$ dunamai from git
1.21.2.post3.dev0+2654c89

$ dunamai from git --commit-length 10
1.21.2.post3.dev0+2654c897c2