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

Hagridden

Sure enough. When the commit is commented out so the script only pushes to a few repositories, it works properly. That is, Hudson recognizes zero changes occurred and waits for changes without looping. So how to stop the infinite loop. It appears that the git plugin for Hudson save the repo state after the initial fetch for the build. But it seems it should save the repo state again after a successful build in case the build did a commit--or at least give that as an option. Any body have a easier, quicker idea to solve this? – Hagridden

Oh, I found a fork of the git-hudson-plugin on github where someone else seems to already have added handling of this situation. I'm downloading and building and will try that. Again if anyone has a better solution, please advise. I'll post back if that solves it. – Hagridden

Answer 1

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

Hagridden

Oh. this is cool! It turns out the Hudson Git plugin already handles this situation. It describes it on the documentation and was over my head a few days ago. The idea is to only commit to "feature" branches. Then the build server first merges the feature branch to an integration branch and then does it's work. That way there's never any need for the automated server to have non-fast forward merges and the commits happen in the integrate branch in the proper order. Awesome. You have got to love the power of Git. – Hagridden

Answer 2

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.

Lesterlesya

Unfortunately, the write must happen because the build must tag the revision with a release number like 0.5.6.135 and also update source files with the number so the compiled binaries have the revision. That allows tracking bugs back to the correct source code. We formerly used SVN and that plugin had an option to "ignore" certain files when polling for changes. So we had it ignore our version files. Git is different, of course. If you know some other way to accomplish the same, let me know please. – Hagridden

I like your idea of not polling for changes actually. The hurdle there is also avoiding the infinite loop of the push from the auto build. So this method also must have a way to compare between the too. That's complex. So polling and comparing seems more straightforward. And polling every 1 minute for changes is definitely not any kind of work for a computer to fret about doing. – Hagridden

FYI, I realize now why you say the build should never write to the repository. I have it all set up and working but the CI build machine writes and creates non-fastword commits when it does that at the end of the build while coders continue coding and committing during the build. Complex, but necessary requirements. I will post another question to tackle this. – Hagridden