Travis: "LibGit2Sharp.NotFoundException: object not found - no match for id ({id})"

[qmfrederik]

I just enabled NB.GV for a repository which uses Travis, and builds started failing with:

The "Nerdbank.GitVersioning.Tasks.GetBuildVersion" task failed unexpectedly. 
LibGit2Sharp.NotFoundException: object not found - no match for id (f7c0aa34d3067615717c1d2eeee22859461d4e24) 
    at LibGit2Sharp.Core.Ensure.HandleError(Int32 result)
    at LibGit2Sharp.Core.Proxy.git_revwalk_next(RevWalkerHandle walker)
    at LibGit2Sharp.CommitLog.CommitEnumerator.MoveNext()
    at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
    at Nerdbank.GitVersioning.VersionOracle..ctor(String projectDirectory, Repository repo, ICloudBuild cloudBuild, Nullable`1 overrideBuildNumberOffset, String projectPathRelativeToGitRepoRoot) 
    at Nerdbank.GitVersioning.VersionOracle.Create(String projectDirectory, String gitRepoDirectory, ICloudBuild cloudBuild, Nullable`1 overrideBuildNumberOffset, String projectPathRelativeToGitRepoRoot) 
    at Nerdbank.GitVersioning.Tasks.GetBuildVersion.ExecuteInner()

See https://travis-ci.org/kubernetes-client/csharp/jobs/371967939 for an example.

Any idea what's going on here?

[AArnott]

You need to disable shallow cloning.

[AArnott]

This and other cloud build requirements of nerdbank.gitversioning

Documentation to disable shallow clone on Travis CI

git:
  depth: false

[qmfrederik]

@AArnott Yup, disabling shallow cloning fixed the issue.

But I'm not sure why it's required in this case? There was a clone depth of 50 and version.json was updated in the previous commit. Why was the code going back beyond the last commit which updated version.json?

[AArnott]

We walk back until we find a version.json file that changes the major.minor version number in order to establish git height. The height isn't reset simply from touching version.json -- it is only reset by a change in the major.minor version. Perhaps that's it?

[qmfrederik]

Well, version.json was newly created in the latest commit (this build was for a PR which tries to introduce NB.GV), so both major & minor changed (though major is set to 0)

Full history is here should you want to have a look:

• Commit : kubernetes-client/csharp@d8458c2
• PR (which only contained this commit) for which the build failed: Use automatic versioning kubernetes-client/csharp#149

[AArnott]

Interesting. I may have forgotten what NB.GV needs to walk more of the history for, or perhaps there is an inefficiency in NB.GV that could be fixed.
Given the right thing in general though is a deep clone, which would make this go away, it feels low priority to investigate enough that it falls below my own interest level.