GitVersion concurrency issue when accessing cache

[simonejsing]

We have a parallelized build that uses GitVersion in individual msbuild projects. GitVersion seems to have a concurrency issue when multiple concurrent process are accessing the cache which results in build warnings. According to the warning this results in undefined assembly versions.

Is this considered a bug, or should we be avoiding concurrent GitVersion calls?
Is there an argument to bypass the cache?

The warning that is generated is:
MSBUILD : warning : WARN [06/29/16 15:43:29:33] Could not determine assembly version: System.IO.IOException: The process cannot access the file 'C:\Workspace\HCM\ApplicationCommon.git\gitversion_cache\B80F8F1DCE4B87563E9EE9C979A45AEE8086132C.yml' because it is being used by another process.
MSBUILD : warning : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
MSBUILD : warning : at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
MSBUILD : warning : at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
MSBUILD : warning : at System.IO.File.OpenWrite(String path)
MSBUILD : warning : at GitVersion.Helpers.FileSystem.OpenWrite(String path)
MSBUILD : warning : at GitVersion.GitVersionCache.WriteVariablesToDiskCache(IRepository repo, String gitDir, VersionVariables variablesFromCache)
MSBUILD : warning : at GitVersion.ExecuteCore.ExecuteGitVersion(String targetUrl, String dynamicRepositoryLocation, Authentication authentication, String targetBranch, Boolean noFetch, String workingDirectory, String commitId, Config overrideConfig)
MSBUILD : warning : at GitVersion.ExecuteCore.TryGetVersion(String directory, VersionVariables& versionVariables, Boolean noFetch, Authentication authentication)

[asbjornu]

@simonejsing Thanks for discovering this. It is indeed a bug. It's currently not possible to avoid caching and I'd rather see that we fix the concurrency bug than add more arguments and/or configuration values. Would you like to have a go at trying to fix the problem in a PR?

[simonejsing]

Yeah I can take a look at it. My current thinking is that we should simply swallow IO exceptions on cache write, since missing a cache write is no big deal, and the most likely reason we missed the write is that another process is already writing it. In any case if a complete failure to write the cache happened for some reason, the next process would retry the operation. Worst case cache write fails consistently which would incur a performance hit.

[simonejsing]

PR #920 submitted.