9

The Windows 7 machine running our Jenkins server is having some trouble with git.

Our code is hosted on GitHub and builds are run nightly. First thing the job does is checkout branch X from GitHub then runs the build scripts. Unfortunately we've noticed that builds appear to get 'stuck.' Every day the same build comes out. When I check the server's git history it's a week behind! Running

git fetch origin

gives no errors but the origin/MyBranch is said to be at a commit from last week, when since then we've made dozens of commits to that branch. Doing a fetch from any other computer or even from another folder on the server works fine and gets the latest changes.

I've tried fetching using different ssh keys/logins from the server and in that particular copy of the repo fetchin is broken. The odd thing is, if we trigger builds from pull requests or OTHER branches they work perfectly. It's only this one particular branch.

The only solution we've figured out so far is to delete the git workspace and start from scratch.

the git version is 1.8.5.2.msysgit.0 and it's usually run by Jenkins...I'm wondering if Jenkins is doing something to the repository to corrupt or lock it up.

EDIT:

output of git remote -vv

origin  git@github.com:Org/Project.git (fetch)
origin  git@github.com:Org/Project.git (push)

EDIT2:

Inspired by the post linked here i tried

git merge FETCH_HEAD

and this worked! However, if I try

git merge origin/branch

this is still stuck at the old commit.

The Jenkins output looks like this

$ git.exe rev-parse --is-inside-work-tree

Fetching changes from the remote Git repository

$ git.exe config remote.origin.url git@github.com:Org/Project.git

Fetching upstream changes from git@github.com:Org/Project.git

$ git.exe --version

$ git.exe fetch --tags --progress git@github.com:Org/Project.git +refs/pull/:refs/remotes/origin/pr/

$ git.exe rev-parse "origin/Branch^{commit}"

Checking out Revision 44c0173b4a4852644a017cff7ecc0441eb209092 (origin/Branch)

$ git.exe config core.sparsecheckout

$ git.exe checkout -f 44c0173b4a4852644a017cff7ecc0441eb209092

$ git.exe rev-list 44c0173b4a4852644a017cff7ecc0441eb209092

44c0173b4a4852644a017cff7ecc0441eb209092 is the SHA for the old commit.

Community
  • 1
  • 1
Boumbles
  • 2,473
  • 3
  • 24
  • 42
  • What is the output of `git remote -vv`? – ChrisGPT was on strike Jun 13 '14 at 19:57
  • Duplicate? [FETCH_HEAD reference not updating correctly after “git fetch”](http://stackoverflow.com/questions/11478558/fetch-head-reference-not-updating-correctly-after-git-fetch) – Jeff Ward Jun 14 '14 at 01:01
  • Strange, I thought git 1.8.4 took care of that: http://stackoverflow.com/a/20967347/6309 – VonC Jun 14 '14 at 05:57
  • @Chris made some updates with more output from the system – Boumbles Jun 19 '14 at 12:11
  • Our temporary solution was to set a pre-build step to [wipe the workspace](https://wiki.jenkins-ci.org/display/JENKINS/Workspace+Cleanup+Plugin) and clone from scratch each time. – Boumbles Jun 26 '14 at 12:59
  • @Boumbles, I ran into the same issue, also using jenkins, and my workaround was instead of `git fetch && git merge origin/branch && git push origin branch` I did `git fetch origin branch && git merge FETCH_HEAD && git push origin branch`. However, I later noticed that jenkins' user account had git 1.7.1 in it's path instead of git 2.4.1, so the original code is probably fine with the new version. – redbmk Jul 11 '15 at 00:32

0 Answers0