Trying to use GitVersion dotnet tool with .net core 3 sdk docker image that runs on GitLab Shared Runner (which is CoreOS).
The 5.0.2-beta.1+95 (contains https://github.com/GitTools/GitVersion/pull/1849) throws this exception:
Using Docker executor with image mcr.microsoft.com/dotnet/core/sdk:3.0 ...
Pulling docker image mcr.microsoft.com/dotnet/core/sdk:3.0 ...
Using docker image sha256:4422e7fb740c14af167b232a7b485d60a1a696a6507ee75e712817bd27dacdb5 for mcr.microsoft.com/dotnet/core/sdk:3.0 ...
...
$ dotnet tool restore
Tool 'gitversion.tool' (version '5.0.2-beta1.95') was restored. Available commands: dotnet-gitversion
Restore was successful.
$ dotnet tool run dotnet-gitversion /updateassemblyinfo /ensureassemblyinfo
INFO [10/10/19 18:18:06:48] Working directory: /builds/nZeus/my-project/sources
INFO [10/10/19 18:18:06:49] IsDynamicGitRepository: False
ERROR [10/10/19 18:18:06:51] An unexpected error occurred:
System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.
---> System.DllNotFoundException: Unable to load shared library 'git2-7ce88e6' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libgit2-7ce88e6: cannot open shared object file: No such file or directory
at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary()
at LibGit2Sharp.Core.NativeMethods..cctor()
--- End of inner exception stack trace ---
at LibGit2Sharp.Core.NativeMethods.git_buf_dispose(GitBuf buf)
at LibGit2Sharp.Core.Proxy.git_buf_dispose(GitBuf buf)
at LibGit2Sharp.Core.Handles.GitBuf.Dispose()
at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever)
at LibGit2Sharp.Core.Proxy.git_repository_discover(FilePath start_path)
at LibGit2Sharp.Repository.Discover(String startingPath)
at GitVersion.GitPreparer.GetProjectRootDirectory() in D:\a\1\s\src\GitVersionCore\GitPreparer.cs:line 160
at GitVersion.Configuration.ConfigFileLocator.Verify(GitPreparer gitPreparer, IFileSystem fileSystem) in D:\a\1\s\src\GitVersionCore\Configuration\ConfigFileLocator.cs:line 56
at GitVersion.Program.VerifyConfiguration(Arguments arguments, IFileSystem fileSystem) in D:\a\1\s\src\GitVersionExe\Program.cs:line 155
at GitVersion.Program.VerifyArgumentsAndRun() in D:\a\1\s\src\GitVersionExe\Program.cs:line 101
INFO [10/10/19 18:18:06:52]
INFO [10/10/19 18:18:06:52] Attempting to show the current git graph (please include in issue):
INFO [10/10/19 18:18:06:52] Showing max of 100 commits
as I mentioned https://github.com/GitTools/GitVersion/issues/1824#issuecomment-540716967 the debian 10 is not yet supported. I'll need to think of a way to make it supported
what do you think about the idea of having another version of GitVersion tool with that dependency included or ilmerged?
GitLab CI runners are based on CoreOS and I cannot find a way to install packages there :(
Are you able to run Docker images there? is so I'd recommend to use the image https://hub.docker.com/layers/gittools/gitversion/5.0.2-beta1-95-linux-debian-9-netcoreapp3.0/images/sha256-ba496f1885415be1bcac0256f0b1af4b6d1ab48db2d1de6116ce6e15462cf419
This image throws a different error:
ERROR [10/17/19 22:01:58:10] An unexpected error occurred:
System.IO.DirectoryNotFoundException: Can't find the .git directory in sh
at GitVersion.GitPreparer.GetProjectRootDirectory() in D:\a\1\s\src\GitVersionCore\GitPreparer.cs:line 165
at GitVersion.Configuration.ConfigFileLocator.Verify(GitPreparer gitPreparer, IFileSystem fileSystem) in D:\a\1\s\src\GitVersionCore\Configuration\ConfigFileLocator.cs:line 56
at GitVersion.Program.VerifyConfiguration(Arguments arguments, IFileSystem fileSystem) in D:\a\1\s\src\GitVersionExe\Program.cs:line 155
at GitVersion.Program.VerifyArgumentsAndRun() in D:\a\1\s\src\GitVersionExe\Program.cs:line 101
Since others will come here looking for the same thing for alpine-3.9 it should be mentioned that alpine 3.9 was only supported in the most recent published packages. 5.0.2.beta+
Also spotted on Ubuntu 19.04+libcurl4
When will GitVersion be supported on Debian 10?
It seems guys have figured out a root cause https://github.com/libgit2/libgit2sharp/pull/1741
See this discussion https://github.com/libgit2/libgit2sharp/pull/1732
I guess now it is required a new release to be built.
Temporary solution for Docker:
export LD_LIBRARY_PATH=/root/.nuget/packages/gitversion.tool/5.1.2/tools/netcoreapp3.0/any/runtimes/debian.9-x64/native/
@deadman2000 thanks for sharing
Can we get a fix for this? We are struggling with this issue as well under amazon linux.
@robertcoltheart, doesn't @deadman2000's LD_LIBRARY_PATH solution work for you?
@asbjornu No, the above export command doesn't seem to help, we are still getting the same error
@robertcoltheart If you use GitVersion as tool, this Dockerfile should helps:
ARG DOTNET_SDK=3.0
FROM mcr.microsoft.com/dotnet/core/sdk:$DOTNET_SDK
ENV PATH="${PATH}:/root/.dotnet/tools"
ENV GITVERSION_VERSION=5.1.2
RUN dotnet tool install -g GitVersion.Tool --version $GITVERSION_VERSION
ENV LD_LIBRARY_PATH=/root/.dotnet/tools/.store/gitversion.tool/${GITVERSION_VERSION}/gitversion.tool/${GITVERSION_VERSION}/tools/netcoreapp3.0/any/runtimes/debian.9-x64/native/
Hmm, we don't use docker currently for the EC2 instances. Will investigate further if the above can be adapted for our use case or not.
Doesn't look like this will work for us. For clarification, we are using linux-x64 on Amazon linux AMI 2. Not debian. Any solution on the horizon that will fix this without having to set exports or hack scripts together to make it work?
The solution that worked for us was to bump LibGit2Sharp to version 0.27.0-preview-0034 and the native binaries version to 2.0.298. For now we are building this locally and hosting our own binaries, but it would be great if this repo could be updated similarly so that we can use the 'official' sources.
@robertcoltheart thanks for sharing, will take that into consideration
This was working on Azure DevOps prior to Christmas using the LIBPATH fix, but it's broken now - anyone have a fix?
We built our own version of GitVersion internally against 0.27.0-preview of LibGit2Sharp. Less than ideal but 馃し鈥嶁檪.
What you're saying is that 0.27.0-preview of LibGit2Sharp fixes the problem, @robertcoltheart? If so, I wonder about the ETA of 0.27.0 and if it's too far into the future, we should perhaps upgrade to the preview in GitVersion?
Yes it fixed our use case which was AWS Linux
Is there any official way to support this? We're using our internal version but it would be nice to have this properly fixed.
@robertcoltheart , currently we are almost ready to release 5.3.0. I would prefer to use a stable version of LibGit2Sharp in this release instead of using a preview. But depending on the response https://github.com/libgit2/libgit2sharp/pull/1741#issuecomment-623280758 we might consider using the preview as well
I commented on the the LibGit2Sharp issue as well, but I don't think we'll be doing a non-preview release any time soon. The work in that PR is mostly a patch to a larger problem that is still being worked on. Even using the preview release that includes that change, there are more Linux distros out there supported by .NET Core that won't work with LibGit2Sharp.
The real fix is to move the support for https into managed code, and that work is ongoing, though progressing slowly.
Thanks @bording. @arturcic any chance of having a preview version of GitVersion that uses the 0.27 preview of Libgit2sharp? 馃槃 At least that will solve our immediate issue, which is custom building a custom fork of Gitversion and hosting it on a custom feed internally.
I think I will update Libgit2Sharp to preview version and will release it as 5.3.2
:tada: This issue has been resolved in version 5.3.2 :tada:
The release is available on:
Your GitReleaseManager bot :package::rocket:
Thank you for the update!
Today I tried version 5.3.2, but it doesn't work, but no libgit error anymore:

Probably it's a different issue. I'll try to investigate. Do you have any ideas about why it can fail and why it doesn't produce any output?
Created a separate story for the described behavior - https://github.com/GitTools/GitVersion/issues/2260
@nZeus the GitLab shared Linux runners are now based on Debian 10, so I got GitVersion to work using @deadman2000's workaround above, just before I run my Cake build. See https://github.com/gitfool/Cake.Dungeon/commit/0655e23b94507896637f21d5636bfd8640542e75.
Most helpful comment
Temporary solution for Docker: