I have a few NUGET packages that I’ve published in NUGET.ORG. I typically build and publish those projects using a YAML file, in an Azure pipeline. That process has worked well right up until I created my latest NUGET package, and tried to run it’s pipeline.
Some background first:
All my NUGET packages use essentially the same YAML file, with just a few changes for the individual solution name, and such.
All my NUGET packages also use a NUGET package called Nerdbank.GitVersion to ensure that I never try to publish the same version twice. That package may be found HERE.
So far, so good. I’ve published about 150 or so packages this way. The process usually works just fine…
… Until this last time I tried it.
I started getting this error, in Azure:
shallow clone lacks the objects required to calculate version height. use full clones or clones with a history at least as deep as the last version height resetting change.
Huh, that had never happened before. I tried Googling the error and came across this page: https://github.com/dotnet/Nerdbank.GitVersioning/issues/423
So, I knew that the author of the Nerdbank.GitVersion NUGET package was aware of the problem. Trouble is, that page didn’t include a way to fix the underlying issue.
What the heck is a “shallow clone” and when did this become a thing? I did some more Googling and discovered that this is a nifty new way, in GIT, to avoid pulling down all the history for a project. That’s, apparently, a thing to be concerned about with really big projects, with lots of history. My NUGET packages are typically small and they really don’t ever have a ton of history. As a result, I really don’t care about this.
Someone changed something, somewhere. Not sure if the culprit is GITHUB, or Visual Studio, or Azure, or Nerdbank.GitVersion. I did some more Googling …
Then I discovered that there is a setting, in the YAML for an Azure CI/CD pipeline, that can step around this issue. That little bit of code is this:
steps: - checkout: self fetchDepth: 0
So, I assume, Azure is the one that changed the default behavior of GIT checkouts, to use a fetch depth of 1, by default. That’s essentially like saying ‘I don’t want any history’. Nice of Microsoft to make that change, and break Azure CI/CD builds in the process. Setting the fetch depth to 0 says ‘I want all my history in the clone’. That’s what I need, all the history.
By the way, the page that led me to that solution is HERE.
This post is just so I won’t forget this, the next time I spin up a new NUGET package. I hope it also helps anyone else in this same situation.
Photo by Daria Nepriakhina 🇺🇦 on Unsplash
