CODEWITHSUNDEEP
gitjenkins-pipeline
GuD
GuD

Reputation: 748

"Thread safe" git pull or how to avoid ".../.git/index.lock': File exists."

Suppose I havbe two Jenkins builds that sometimes start together, if they both require the same git repository and try to pull together, one of them will fail with:

fatal: Unable to create '/project_path/.git/index.lock': File exists.

Is there a better way to go about it other than checking if "index.lock" exists?

Upvotes: 2

Views: 808

Answers (1)

torek
torek

Reputation: 490168

As Daniel Alder notes, papering over this particular error leaves you with a deeper, more malignant error.

While git pull is not specifically the problem, this is another symptom of the kind of problem that arises from using git pull. If you avoid git pull, by replacing every git pull with the two Git commands that Git git pull runs, the problem may be more obvious (or maybe will just move into the second Git command 😉):

git fetch && git merge

or:

git fetch && git rebase

(but don't do this either!).

The problem, which I hope is now obvious but maybe is just hidden inside the second half of the && here, is that git merge or git rebase will modify the work-tree. If you have some command(s) working in the work-tree while you modify the work-tree, those commands will see inconsistent sets of files.

Suppose, for instance, that git merge or git rebase will modify both main.py and routine.py. It might modify main.py first, and just at that moment, a Python interpreter will load up and use the updated main.py that needs new code from routine.py, but Git itself has not yet gotten around to updating routine.py.

The usual way to avoid this problem is to be sure that the work-tree is up to date before starting any operations, whether those are Jenkins jobs, stages within a single Jenkins job, or just anything you intend to run yourself. Once the work-tree is up to date, you never need to git pull, because it's up to date.

If you want to have a Jenkins job run particular Git commands, that job probably needs to have its own private work-tree. A private work-tree, whether it's the main work-tree of a separate repository or just an added work-tree of a shared repository, has its own HEAD and index, and therefore a private index.lock as well.

Upvotes: 2

Related Questions