Community
Participate
Working Groups
Some Hudson jobs depend on "changes in CVS" to trigger a build. Such as https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.runAggregator/ I noticed it had not "kicked off" lately, even though I knew there were changes, so I checked its "cvs polling log" at https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.runAggregator/scmPollLog/? and found this message Started on Oct 29, 2011 6:45:28 PM ERROR: Failed to record SCM polling java.lang.NullPointerException at hudson.model.AbstractProject.poll(AbstractProject.java:1336) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) This is disconcerting since NPEs are sometimes a problem with code (not infrastructure). I will try clearing our workspace of previously cached cvs data, which should trigger a build ... we'll see if that does any better ... but, even if "solves" the immediate problem .... thought I should report this NPE in case others see it too.
When workspace was empty (having be cleared "manually") then next cvs poll did detect it was empty, and pulled in a new version (and triggered a build). But, I tried a small tweak to a file in cvs to see if next one would work, and got the same NPE. I did see http://issues.hudson-ci.org/browse/HUDSON-8881 which describes the problem in "2.0.0" but "fixed in 2.1.0" which is what I think we are using? (But, I am not sure what we at eclipse are using, exactly, and what, in turn, bug tracking system it is using).
(In reply to comment #1) > which describes the problem in "2.0.0" but "fixed in 2.1.0" which is what I > think we are using? Yup. -M.
I think I know what the problem is ... sort of. According to http://wiki.hudson-ci.org/display/HUDSON/CVS+Plugin the bug is in the CVS Plugin, and it is fixed in version 2.1.0 of the CVS Plugin. to investigate, since I can't see the plugin versions on eclipse.org, I installed a version of Hudson 2.1.0 on my local machine, and see that is "comes with" only version 2.0.1 of the CVS Plugin, not 2.1.0. So ... can you update (just) the CVS Plugin? I could not see a way, on my "local" system. But, I checked the "2.1.1" version of the war file, and it has version 2.1.0_1 version of the CVS plugin. I suspect the "2.1.0 package" was a bit of mistake, given that what I see contradicts what they say elsewhere, such as at http://hudson-ci.org/changelog.html Without the ability to detect cvs changes, Hudson is about worthless to me ... I (or someone) must manually start every Simultaneous Release aggregation build.
Ok, I've upgraded Hudson to 2.1.2. While under the 'manage plugins' link there is a way to upgrade the CVS plugin, with text like 'Warning this plugin is for version for Hudson version X. It may not work with your installation' I really wasn't keen on trying that. -M.
Thanks for the quick fix. Seems to be working again. I've added a comment to Hudson bug http://issues.hudson-ci.org/browse/HUDSON-8881 And now we are out of "upgrades" for whatever regressions we run into next :) Of course, I'm sure they'll have another for their community to test with in a week or so :)
