Hudson infinite loop polling for changes in Git repository?

Question

The git plugin for hudson works well. However, the build script must update a version number in the files in the repository, commit, and push back to the repository.

When Hudson polls next to check for changes, it goes into an infinite loop because it sees that commit as a "change" builds again, which commits a change, so it builds again, then it commits another change, etc... You get the idea.

I stopped it, ran a "git log" in each repository and compared the latest commit ids are exactly the same using git ls-tree HEAD

Also, Hudson runs this command to check for changes:

git fetch +refs/heads/:refs/remotes/origin/ git ls-tree HEAD

Since Hudson itself pushed the commit from its workspace repository, and apparently the ls-tree results match, how can this command determine that there as been a change?

It seems that it must be storing the results of ls-tree prior to doing the build and comparing to that which won't have the latest commit. Ah. I can try turning off the commit to test that theory.

Anyway, rather than fix any issue in the git plugin for Hudson, what can I do to make sure at the end of my build that the repos are identical and that Hudson will see it so.

How to fix this? Any ideas?

Wayne

Answer 1

Your build system should not have any write interaction with your revision control system. It most certainly shouldn't push those changes automatically.

Your build system may ask git (via git describe, for example) what the current revision is. Anything else is redundant and error prone.

Another thing you may consider is not polling for changes. That seems like a silly way to operate. (Admittedly, I'm a heavy buildbot user quite accustomed to having everything be triggered on events.)

The git repo that's being polled knows when it changes. It should just tell the CI system to start a build immediately based on that. You get your builds sooner and since they're all triggered, you don't have your computers sitting around doing lots of work for no good reason.

Answer 2

And the answer is!...

The Git Hudson plugin was already forked by someone to add this feature it works well. Still, I had to pull down the source and fix a couple of minor issues.

Now it works beautifully. The build commits, and the Git plugin pushes back to the repository without looping, thinking it has again changed.

Wonderful!

If someone else needs this look for the tickzoom fork of the Hudson-GIT-Plugin on Github.com but check to see if has already been integrated back in to the main project. The committer said he was interested and planning on combining the forks.

Wayne