GetBuildVersion fails with NullReferenceException when git clone depth is 1 #423
Comments
|
Agreed. I'll see what we can do to improve the error message here. |
|
Just a +1 - experienced a similar issue with actions/checkout@v2 with default parameters. For reference, this was the fix: |
|
Let's see if libgit2sharp can fix it: libgit2/libgit2sharp#1775 |
workaround nedbank.gitversion issue dotnet/Nerdbank.GitVersioning#423
* Create build.yml
* Update Nerdbank.GitVersioning for GitHub actions support
* Attempt to work around shallow clone issues with LibGit2Sharp
See: dotnet/Nerdbank.GitVersioning#423
See: libgit2/libgit2sharp#1775
* Skip RabbitMQ integration tests when no connection string configured
* Remove dummy service bus connection string to skip Service Bus integration tests
* Skip additional service bus tests when no connection string available
* Skip additional RabbitMQ tests when no connection string is available
* Attempt to get rabbitmq service container working
* Attempt to connect to rabbitmq service container for tests
* Skip rabbitmq management tests if neither connectionstring or management uri configured
* Add service bus connection string secret
* Attempted OS matrix builds for linux and windows builds
* Revert "Attempted OS matrix builds for linux and windows builds"
* Add coverlet flags to dotnet test
* Attempt to store test coverage artifact
* Remove flaky rabbitmq connection finalizer tests
Just to note, setting fetch-depth: 0 will fetch the full git history during CI, which, for large repositories, can take quite some time. If you change your minor version at least sometimes, then setting this to a reasonable restricted value, like 100 or 1000 (depending on your minor versioning frequency), will also work. |
|
I've experienced different, but related error caused by fetch-depth of 1 (default of actions/checkout@v2), that was fixed by set fetch-depth to 0. Related build log info: Full job run info here |
|
Duplicate of #92 |
|
Looks like Azure DevOps changed the default settings to use shallow fetch = 1.
This breaks new pipelines that use ngvb that don't set the fetch depth explicitly. https://dev.to/kkazala/azure-devops-pipelines-shallow-fetch-1-is-now-default-4656 has the solution for YAML: steps:
- checkout: self
fetchDepth: 0According to the docs, the YAML config is supposed to take precedence over the UI setting. |
|
In my case, I have a submodule that appears to be breaking a new Azure Pipeline that I created today. I have |
|
OK I got it working! I believe this had to do with a bad |
For reproduction purpose consider this commit: c80k/capnproto-dotnetcore@5208531
which seems to fix the problem.
Background: The project is built inside an AppVeyor CI. Without the former commit, you'll see something like this in the log:
The fix just removes the
clone_depthproperty from appveyor.yml.I understand that cloning the complete repository (i.e. not limiting the clone depth) is essential for calculating the correct version info. My problem was that I totally forgot about the clone depth restriction being set, and that I had a hard time figuring out that this was the actual cause. A meaningful error message instead of letting
GetBuildVersionfail unexpectedly would be nice. :-)The text was updated successfully, but these errors were encountered: