LibGit2Sharp.LockedFileException: The index is locked. This might be due to a concurrent or crashed process

[michaelnoonan]

Wasn't sure if this was an issue or whether we shouldn't be using msbuild /m to enable concurrent builds.

[11:45:48]  [BuildSolution]     17>MSBUILD : warning : WARN [09/02/16 1:45:48:65] Could not determine assembly version: LibGit2Sharp.LockedFileException: The index is locked. This might be due to a concurrent or crashed process [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Core.Proxy.git_checkout_tree(RepositoryHandle repo, ObjectId treeId, GitCheckoutOpts& opts) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Repository.CheckoutTree(Tree tree, IList`1 paths, IConvertableToGitCheckoutOpts opts) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Repository.Checkout(Tree tree, CheckoutOptions checkoutOptions, String refLogHeadSpec) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Repository.Checkout(Branch branch, CheckoutOptions options) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at LibGit2Sharp.Repository.Checkout(String committishOrBranchSpec, CheckoutOptions options) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at GitTools.Git.GitRepositoryHelper.EnsureLocalBranchExistsForCurrentBranch(Repository repo, String currentBranch) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at GitTools.Git.GitRepositoryHelper.NormalizeGitDirectory(String gitDirectory, AuthenticationInfo authentication, Boolean noFetch, String currentBranch) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at GitVersion.GitPreparer.Initialise(Boolean normaliseGitDirectory, String currentBranch) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at GitVersion.ExecuteCore.ExecuteGitVersion(String targetUrl, String dynamicRepositoryLocation, Authentication authentication, String targetBranch, Boolean noFetch, String workingDirectory, String commitId, Config overrideConfig) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]
[11:45:48]  [BuildSolution] MSBUILD : warning :    at GitVersion.ExecuteCore.TryGetVersion(String directory, VersionVariables& versionVariables, Boolean noFetch, Authentication authentication) [Y:\Work\refs\heads\master\source\Octopus.E2ETests\Octopus.E2ETests.csproj]

This occurs on TeamCity 10.0.0 building ~30 projects. We've only just upgraded to GitVersionTask.3.6.3 from GitVersionTask.3.6.1 which had the gitversion_cache issue.

In the meantime I'll try some more builds and see if it recurs frequently.

[michaelnoonan]

The very next build through TeamCity failed with the exact same message and stack trace.

I'm going to revert to msbuild without the /m for now.

[JakeGinnivan]

Id switch to the exe, run it with /updateAssemblyInfo before building.

We would have to grab a mutex, and block builds until the first task has finished calculating the version then unblock the others and they get the version from the cache.

[asbjornu]

Perhaps we could use .git/index.lock for this? I believe it would be semantically correct to lock the entire Git repository for all and any change meanwhile we calculate a version. If .git/index.lock exists, we could await version calculation until it's deleted or within a configurable time-out.

[JakeGinnivan]

Im happy with that

[bbowman]

any updates here?

[asbjornu]

@bbowman: I'm sorry, but nothing has happened besides agreeing on a solution that is yet to be implemented. We need someone in the team to have time to implement this, or get someone else to submit a PR. I unfortunately have my hands full. Perhaps you or @michaelnoonan can submit a PR?

[jnevins-gcm]

any update on this? builds take 4x as long without parallelism :(

[asbjornu]

@jnevins-gcm: Sorry, there's nothing new to report on this. If you are able to provide a pull request that fixes this as described in #1031 (comment), it will be merged quickly provided it passes all tests.

[jnevins-gcm]

Thanks for the update. Even if I fix, how would I manage to get that into GitVersionTask?

Is there any short term workaround I could do with retries?

[asbjornu]

@jnevins-gcm, if you submit a pull request to this repository, it will be merged and a new package of GitVersionTask will show up on NuGet that you can use.

[asbjornu]

Now that we've upgraded to LibGit2Sharp version 0.26 in #1713, I hope this problem might be fixed. Please test with the latest v5 beta and reopen if the problem persists.

[StevenDevooght]

Hi,

We are having the same issue using the latest beta version (5.0.0-beta5.11).

[borrillis]

Also hitting this issue on linux and Windows (but not MacOS) build agents using GitVersion 5.0.1