GitVersion on VSTS fails with hosted macOS and Linux agents

[jmezach]

Since version 4.0.0 of GitVersion it seems to be supported to use the GitVersion build task in VSTS on a macOS and/or Linux agent. I've been trying this, but I'm getting the following error:

2018-10-15T07:23:59.0448310Z ##[section]Starting: GitVersion
2018-10-15T07:23:59.0453140Z ==============================================================================
2018-10-15T07:23:59.0453290Z Task         : GitVersion Task
2018-10-15T07:23:59.0453470Z Description  : Easy Semantic Versioning (http://semver.org) for projects using Git
2018-10-15T07:23:59.0453680Z Version      : 4.0.3
2018-10-15T07:23:59.0453810Z Author       : GitVersion Contributors
2018-10-15T07:23:59.0454010Z Help         : See the [documentation](http://gitversion.readthedocs.org/en/latest/) for help
2018-10-15T07:23:59.0454210Z ==============================================================================
2018-10-15T07:23:59.6549950Z [command]/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono /Users/vsts/agent/2.140.2/work/_tasks/GitVersion_e5983830-3f75-11e5-82ed-81492570a08e/4.0.3/GitVersion.exe /Users/vsts/agent/2.140.2/work/1/s /output buildserver /nofetch /updateassemblyinfo true
2018-10-15T07:24:00.1372460Z INFO [10/15/18 7:24:00:10] Working directory: /Users/vsts/agent/2.140.2/work/1/s
2018-10-15T07:24:00.1530150Z INFO [10/15/18 7:24:00:15] IsDynamicGitRepository: False
2018-10-15T07:24:00.2123180Z ERROR [10/15/18 7:24:00:21] An unexpected error occurred:
2018-10-15T07:24:00.2124820Z System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: git2-15e1193
2018-10-15T07:24:00.2125630Z   at (wrapper managed-to-native) LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
2018-10-15T07:24:00.2125880Z   at LibGit2Sharp.Core.NativeMethods.LoadNativeLibrary () [0x00000] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2126040Z   at LibGit2Sharp.Core.NativeMethods..cctor () [0x00054] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2126620Z    --- End of inner exception stack trace ---
2018-10-15T07:24:00.2126860Z   at LibGit2Sharp.Core.Proxy.git_buf_free (LibGit2Sharp.Core.Handles.GitBuf buf) [0x00000] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2127520Z   at LibGit2Sharp.Core.Handles.GitBuf.Dispose () [0x00000] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2127730Z   at LibGit2Sharp.Core.Proxy.ConvertPath (System.Func`2[T,TResult] pathRetriever) [0x0002e] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2127910Z   at LibGit2Sharp.Core.Proxy.git_repository_discover (LibGit2Sharp.Core.FilePath start_path) [0x00005] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128080Z   at LibGit2Sharp.Repository.Discover (System.String startingPath) [0x00006] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128230Z   at GitVersion.GitPreparer.GetDotGitDirectory () [0x0000f] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128370Z   at GitVersion.GitPreparer.GetProjectRootDirectory () [0x00048] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128570Z   at GitVersion.ConfigurationProvider.Verify (GitVersion.GitPreparer gitPreparer, GitVersion.Helpers.IFileSystem fileSystem) [0x00014] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128820Z   at GitVersion.Program.VerifyConfiguration (GitVersion.Arguments arguments, GitVersion.Helpers.IFileSystem fileSystem) [0x00023] in <824ee26b2afa49d5948582decd2171d3>:0 
2018-10-15T07:24:00.2128990Z   at GitVersion.Program.VerifyArgumentsAndRun () [0x00118] in <824ee26b2afa49d5948582decd2171d3>:0 

On Windows this works just fine. I looks like there's a native assembly missing somewhere. Perhaps that's an issue with the bundling of the VSTS extension, or maybe something needs to be installed on the build machine, but I'm not sure.

[arturcic]

can you have a look at this? https://github.com/GitTools/GitVersion/blob/master/src/Docker/linux/fullfx/Dockerfile#L5. Looks like you need you install that

[jmezach]

Hmm, I'm not sure if I can install it on the hosted build agents, will have to look into that. That being said, I'm not sure if it's something you would want. It doesn't make it necessarily easy to use. Would be an option to embed the library into the extension somehow? Does that make sense?

[arturcic]

Actually it is included, there is a lib folder there and it should use that one, but does not seem to work

[jmezach]

Ah, I see it is included in the VSIX indeed, including a version for each platform. But I guess that GitVersion.exe is unable to locate that library at runtime. That begs the question why it works on Windows though. Perhaps the Windows agents have this library installed on the system somewhere? The question is, can we make GitVersion.exe look inside the lib folder.

[arturcic]

I think it's not related to GitVersion but with the way libgit2sharp loads the native methods libgit2/libgit2sharp#1583

[jmezach]

Okay, so it looks like we have 2 options: update libgit2sharp to it's latest version (it seems that GitVersion is using a preview version at the moment?), or move the native libraries next to GitVersion.exe, but then we would probably need to have a different folder structure inside of the build task entirely.

[kll]

Unfortunately GitVersion is extremely fragile due to LibGit2Sharp requiring native binaries for LibGit2 which in turn require correct versions of libssl and libcurl and vary from one distribution to the next. It might get better soon if the LibGit2Sharp developers proceed with this PR which will remove the libssl and libcurl requirements by implementing that functionality directly in managed .NET code rather than funneling it down to the native LibGit2 implementations.

[yohanb]

FYI, I created a PR for a .NET Core build task:
#1499

[uwiedemann]

Under macOS (10.14), I got the command line call running from Terminal by setting the environment variable DYLD_LIBRARY_PATH to the absolute path of _work/tasks/GitVersion*/4.0.3/lib/osx.

As said earlier in this thread by others, I also suspect that GitVersion.exe is not able to find libgit2-*.dylib inside its own subdirectory.

According to otool -L all dependencies of libgit2 are met, e.g. libcurl in /usr/lib.

[arturcic]

As a workaround you can use these libgit2/libgit2sharp#1583 (comment)

[beatcracker]

Under macOS (10.14), I got the command line call running from Terminal by setting the environment variable DYLD_LIBRARY_PATH to the absolute path of _work/tasks/GitVersion*/4.0.3/lib/osx.

This worked for me using Hosted Ubuntu in Azure DevOps. Just add this as your first task in azure-pipelines.yml

- bash: |
    shopt -s nullglob
    function join_by { local IFS="$1"; shift; echo "$*"; }
    lib_path=$(join_by ';' $(Agent.WorkFolder)/_tasks/GitVersion*/4.0.*/lib/linux/x86_64)
    echo LD_LIBRARY_PATH: $lib_path
    echo "##vso[task.setvariable variable=LD_LIBRARY_PATH]$lib_path"
  displayName: Update LD_LIBRARY_PATH for GitVersion

[wesley-pattison]

Under macOS (10.14), I got the command line call running from Terminal by setting the environment variable DYLD_LIBRARY_PATH to the absolute path of _work/tasks/GitVersion*/4.0.3/lib/osx.

This worked for me using Hosted Ubuntu in Azure DevOps. Just add this as your first task in azure-pipelines.yml

- bash: |
    shopt -s nullglob
    function join_by { local IFS="$1"; shift; echo "$*"; }
    lib_path=$(join_by ';' $(Agent.WorkFolder)/_tasks/GitVersion*/4.0.*/lib/linux/x86_64)
    echo LD_LIBRARY_PATH: $lib_path
    echo "##vso[task.setvariable variable=LD_LIBRARY_PATH]$lib_path"
  displayName: Update LD_LIBRARY_PATH for GitVersion

Kind regards, you beautiful human being :)

[jeromelaban]

In case someone needs it for macOS:

  - bash: |
      shopt -s nullglob
      function join_by { local IFS="$1"; shift; echo "$*"; }
      lib_path=$(join_by ';' $(Agent.WorkFolder)/_tasks/GitVersion*/4.0.*/lib/osx)
      echo LD_LIBRARY_PATH: $lib_path
      echo "##vso[task.setvariable variable=LD_LIBRARY_PATH]$lib_path"
    displayName: Update LD_LIBRARY_PATH for GitVersion

[Tankatronic]

Under macOS (10.14), I got the command line call running from Terminal by setting the environment variable DYLD_LIBRARY_PATH to the absolute path of _work/tasks/GitVersion*/4.0.3/lib/osx.

This worked for me using Hosted Ubuntu in Azure DevOps. Just add this as your first task in azure-pipelines.yml

- bash: |
    shopt -s nullglob
    function join_by { local IFS="$1"; shift; echo "$*"; }
    lib_path=$(join_by ';' $(Agent.WorkFolder)/_tasks/GitVersion*/4.0.*/lib/linux/x86_64)
    echo LD_LIBRARY_PATH: $lib_path
    echo "##vso[task.setvariable variable=LD_LIBRARY_PATH]$lib_path"
  displayName: Update LD_LIBRARY_PATH for GitVersion

This is awesome. Worked smooth like butter

[asbjornu]

As LibGit2Sharp was upgraded to version 0.26 in #1713, I hope this problem is remedied. If it isn't, at least we have the workarounds provided by @beatcracker and @jeromelaban above. Can you please try [the latest buildhttps://www.nuget.org/packages/GitVersionCore/5.0.0-beta4-1) and let us know how that works for you? Please reopen if you still have issues.