问题
I've been tasked with maintaining a Jenkins server with jobs that basically check out some code and build it. Currently they do a git clone using the "--depth 1" and "-b {branch}" options to get a specific code branch as quickly as possible. But this is still wasteful since a fresh copy is being checked out (over the network) every time a job executes, even if there are very few (if any) changes.
Instead, what I'd like to do is have a shared local repo on the build machine that's a clone of our remote repo. Each job would do a "git pull" on a specific branch to bring in any changes from the remote repo, then copy the source tree from the repo to its Jenkins workspace before starting the build.
Is this a bad idea?
What concerns me is the possibility that different jobs targeting the same code branch will be run simultaneously, which could result in concurrent "git pull" requests.
Could this result in corruption of Git's meta-data?
Is one of the concurrent pulls likely to fail due to locking issues?
The shared local repo would never have any changes committed to it and nothing would ever be pushed from it to the remote repo. It would be "pull only", so to speak. All the pulls would come from the same user, so there shouldn't be any file permission issues.
Some googling turned up this discussion from 4 years ago, but it doesn't seem conclusive:
http://git.661346.n2.nabble.com/concurrent-fetches-to-update-same-mirror-td5893458.html
回答1:
Is this a bad idea?
Can think of a following scenario.
Assuming Job1 did a git pull and checked out the latest code and started copying from the local git repository to the workspace. At this particular moment, Job2 did a git pull and few of the files got copied when the copy process was still going on (For a large repository, i believe it could be possible). In such cases, you might have files from both the checkouts, which is not something you want. Please correct me, if am wrong in this particular scenario.
Though not part of the original question, adding the below as it might be useful to others.
Since, you've mentioned clearly that you are not going to commit anything back to the git, you don't encounter the race condition.
"hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
child exited with value 1 - "
You'll encounter this error if your job, after the execution, checks in a few files into git (Update version number, changelog etc...). This error occurs when you have checked out a specific revision from git and there has been a fresh check-in in the same branch of the repository and the current job tries to commit the updated files and it finds that the git is not in the same version as it was when it checked out.
- If you are not committing anything back to git, its worth giving it a
try as you can save space / job execution time by avoiding multiple
pull.
- If you commit anything back, its not a good idea to share a single git repository across multiple jobs.
来源：https://stackoverflow.com/questions/27926391/concurrent-git-pulls-to-same-local-repository