Shallow clones can lead to less precise SHA commit digests

[wabrit]

The default behaviour on some CI/CD systems (e.g. Atlassian bitbucket) when cloning a Git repo is to use a specific clone "depth" rather than a full clone.

This appears to lead to less precision in the SHA digest associated with a commit (e.g. from 8 digits with a full clone to just 7 with a shallow clone).

This can cause issues with Pact Brokers if the cloning behaviour is different for e.g. pipelines that publish/verify contracts and those that use can-i-deploy to gate deployment decisions, because the pacticipant versions will not match due to the absolute version in one case picking up a 7 digit SHA digest, and in the other picking up an 8-digit SHA digest.

In the case of Atlassian Bitbucket, use of the specific step parameter

- step:
    ...
    clone:
      depth: full

prevents shallow cloning and ensures a consistent digest length, but its possible the shallow clone effect upon digest length is a specific bug in bitbucket

[TimothyJones]

Thanks for the report! Sorry I didn't see this earlier for some reason.

The idea behind this project was to provide absolutely repeatable versions - perhaps the best behaviour here is to detect the commit SHA length and throw an error if the clone isn't delivering 8 digits? What do you think?

I may need to learn more about what determines the SHA characters.

[wabrit]

Yes I think anything that flags up the issue immediately would be at least a good short-term improvement; it took a while of head-scratching before I spotted the missing digit :-) Plus maybe some warnings in the docs.

But I agree some further investigation into the root cause; it might be a bitbucket issue.

[TimothyJones]

So, I did a bit of reading about this - it seems that git defaults to 7 characters, but will use more if it needs to:

the output will use shorter values but keep them unique; it defaults to using seven characters but makes them longer if necessary to keep the SHA-1 unambiguous:

https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

I wonder if a shallow clone is restricted by not knowing the other commits?

A couple questions:

1. Were the git versions different?
2. Was it the shallow clone that had the shorter short SHA?

[wabrit]

Hi - sorry for the late reply; I'm afraid the original details are a little hazy now (I've worked around the issue by always doing a full clone on BB). To the best of my memory (1) no they were the same git versions, (2) the shallow clone had the shorter SHA.