Summary

When using custom revision to queue a build there is no lock placed on the git cache. Because there's no lock present, when two or more threads fetch on the same directory we encounter git's own protection against concurrent access. The second fetch will fail but then Bamboo detects that the fetch has failed and in an attempt to restore consistency, removes the cache. This causes the other builds to fail when the cache is removed.

Steps to Reproduce

1. Set the concurrent build limit to 6
2. Concurrent calls to /rest/api/latest/queue/PROJ-PLAN?customRevision=revisionhash to plans that share the same git cache (Key is defined by combination of repository URL & username) e.g.

   seq 6 | parallel curl -u admin:password -X POST http://bamboo/rest/api/latest/queue/PROJ-PLAN?customRevision=52b8b228d81723b56be98c1c2ad299bd1b43baa0q!

Expected Results

Lock is placed on the cache so concurrent plans using the same cache with a custom revision don't fail.

Actual Results

The below exception is thrown in the atlassian-bamboo.log file:

com.atlassian.bamboo.plugins.stash.repository.StashRepositoryException: com.atlassian.bamboo.repository.RepositoryException: : Cannot fetch branch 'refs/heads/*' from 'ssh://git@bitbucket:7999/proj/repo.git' to source directory '/var/bamboo-home/xml-data/build-dir/_git-repositories-cache/xxx'. fatal: FETCH_HEAD is empty after fetch.

Multiple plans using the same cache that are triggered using custom revision fail, while some succeed. The number of failing plans and which plans fail, is random.

Workaround

1. Use git repository with HTTP authentication and different usernames on each plan so that the cache is separate per build.
2. Use a script task to execute the source code checkout to bypass the git cache and fetch directly from the repository. Pass the revision in using a variable e.g.

   POST http://bamboo/rest/api/latest/queue/PROJ-PLA?bamboo.variable.customCommit=52b8b228d81723b56be98c1c2ad299bd1b43baa0q