Plugin output vs `git describe`: different commit hash length

[rocketraman]

What happened?

I have a repository in which git describe --tags --always --first-parent returns v2023031601-38-g3b46af6d. However, the plugin returns v2023031601-38-g3b46af6 -- note the commit hash is one letter shorter.

What did you want to happen?

The two outputs should be the same.

$ git --version
git version 2.39.2

[fawind]

Its worth pointing out that the commit hash you are seeing is not the full hash (which is typically 40 characters long) but an abbreviation of the first few characters. The length of this abbreviated hash returned by git describe can vary based on your system or local git settings. I believe on most systems, the default abbreviation length is 7 characters, which is also the length gradle-git-version uses (source code). For gradle-git-version, we always want to return this fixed abbreviation length so you always get the same version, independent of your local environment.

If you want to ensure that git describe uses the same abbreviation length, you can run it with git describe --tags --always --first-parent --abbrev=7.

[rocketraman]

I'm aware of that, but note Git returns 7, or the minimum needed to ensure uniqueness, which is why it returns 8 in this case.

Shouldn't the plugin apply the same logic?

[fawind]

Sorry you're right, I did not consider that git smartly returns you more characters if the default abbreviation is not unique. Yeah, thinking about this again, I tend to agree with you that the plugin should probably incorporate that. The property that your release version always uniquely identifies a point in your git history is probably important to preserve.

I guess one downside would be that we loose some strictness regarding how these versions are structured. We would also need to ensure that downstream consumers of those versions can handle variable length suffixes (i.e. sls-version-java and sls-version-js). I would hope so though!

[rocketraman]

The property that your release version always uniquely identifies a point in your git history is probably important to preserve.

Yes, and in addition, the problem is even worse when the CI system (Google Cloud Build in the case where I encountered this) does not checkout tags, therefore the output consists only of the non-unique abbreviated hash, with no "relative to tag" component.