CODEWITHSUNDEEP
phpgitgithub
Alex Sollman
Alex Sollman

Reputation: 33

Trying to run git pull on server after webhook triggers, not working correctly

We have a PHP script that triggers based on a github webhook to execute git pull on a specific branch. I can run the commands easily manually, but when we try to have the script do it automatically, we keep getting errors.

["error: cannot lock ref 'refs\/remotes\/origin\/dev': ref refs\/remotes\/origin\/dev is at bc75782f3b77b5c03a254cecbf4e16856e2f4155 but expected faa849975f836d8ea4f69c098f1b369aef879c43","From #####:#####\/#####"," ! faa8499..bc75782  dev        -> origin\/dev  (unable to update local ref)"]

Not sure what to do about this, any ideas?

Thanks!

Upvotes: 3

Views: 270

Answers (1)

torek
torek

Reputation: 487755

Given the hash IDs shown, it seems as though you have two or more scripts running more or less simultaneously. One of them starts first and sees that commit bc75782f3b77b5c03a254cecbf4e16856e2f4155—and perhaps some additional commits—are not yet in the local repository, but are in the remote, and begins retrieving them.

At this point, the other script (or one of many of them) starts up. It, too, contacts the remote Git and discovers commit bc75782f3b77b5c03a254cecbf4e16856e2f4155. It too sees that this commit is not yet in the local Git repository. So it begins retrieving any necessary commits.

Somewhere around the time the second script is almost done, the first script finishes. It has your (local) Git update your (local) origin/dev from faa849975f836d8ea4f69c098f1b369aef879c43 to bc75782f3b77b5c03a254cecbf4e16856e2f4155, so as to remember that the remote Git it is talking to, under the name origin, has bc75782f3b77b5c03a254cecbf4e16856e2f4155 as its dev. This finishes successfully and the first script is now done.

The second script now attempts to replace the old origin/dev value with bc75782f3b77b5c03a254cecbf4e16856e2f4155 too. But origin/dev no longer contains the old value: it now has bc75782f3b77b5c03a254cecbf4e16856e2f4155. This generates the fatal error you observe: the second script's run has failed; it cannot update origin/dev because someone else beat it to the update.

The main solution is to avoid running the script so often, so that it doesn't keep racing against other instances of running the script. The secondary one is to ignore this particular error, while not ignoring any other failures to update that aren't due to benign races like this one. It seems likely that Git should consider this a non-fatal error since the value stored in origin/dev is the value that Git wanted to store in origin/dev.

Upvotes: 5

Related Questions