-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
Hudson 1.354, Perforce plugin 1.0.28
My "journey" started with this exception:
14-04-2010 12:43:13 hudson.triggers.SCMTrigger$Runner runPolling SEVERE: Failed to record SCM polling java.lang.NumberFormatException: For input string: "-" at java.lang.NumberFormatException.forInputString(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at java.lang.Integer.(Unknown Source) at com.tek42.perforce.parse.Changes.getChangeNumbers(Changes.java:144) at hudson.plugins.perforce.PerforceSCM.needToBuild(PerforceSCM.java:735) at hudson.plugins.perforce.PerforceSCM.pollChanges(PerforceSCM.java:639) at hudson.scm.SCM.poll(SCM.java:370) at hudson.model.AbstractProject.poll(AbstractProject.java:1157) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:330) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:359) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
I also added this text as a note to JENKINS-1873, thinking it was the same.
Some further analysis revealed which job was failing (only one, consistently). After a while, trying to get output of "p4 changes -m 2 //clientspec/...", I discovered that this particular clientspec was using the wrong Root!
Most of our builds use custom workspaces in the form "${N}/hudson/jobs/${JOB_NAME}/workspace" (N expands to a network drive or mount point, JOB_NAME is a Hudson standard variable).
This job's Perforce clientspec consistently ends up with a root that is the workspace of a different build (one of its downstream builds, but that's probably coincidence). I have tried many things, including deleting the clientspec and letting the plugin start over; still the same thing happened.
[JENKINS-6254] Perforce plugin uses custom workspace from a different job
torbent
added a comment - The latter problem is now tracked as JENKINS-6256 Yeah that sounds like an issue with core.
In any case, here's a few things to check:
First, are your jobs sharing client-workspaces? This would cause other jobs to update the client root (such as your downstream job).
Second, do you have "Don't update client workspace" checked? This would prevent the build from being able to update the root properly. I added that option after complaints that hudson shouldn't change the client spec at all (different workflows, different use-cases, they give me a headache...)
Other than that, I can't think of anything that would cause it to behave THAT crazily. I'll keep the bug open though in case we find something else.
torbent
added a comment - I try to keep a very sane (IMHO, of course) setup. No shared workspaces, always let the plugin manage the workspaces (apart from renaming per slave, except for a few cases). The "Don't update" option is new so I couldn't have fiddled with that yet?
I triplechecked both configurations yesterday and didn't find anything that was different from what it should be. So they're fine (or I'm not seeing it 
).
This happened for a couple of jobs, apparently. Looking at the timing of things, it must have been the day (April 7th) that I upgraded our Hudson from 1.351 to 1.353 and the Perforce plugin from 1.0.24 to 1.0.27. That caused a lot of quick failures because of the LineEnd-being-"null" problem, so I "immediately" downgraded the plugin to 1.0.26.
All of the "moving" builds happened around the same time of the afternoon that day, but I hadn't discovered any problems until I upgraded yesterday ... That's not to say that they weren't there, of course.
I think most, if not all, of these jobs build relatively rarely, so that could be one reason I didn't see it?
Anyway, I've kept it running on 1.354+1.0.28 overnight and it appears to be ok. I'll keep watching it, of course!
torbent
added a comment - I try to keep a very sane (IMHO, of course) setup. No shared workspaces, always let the plugin manage the workspaces (apart from renaming per slave, except for a few cases). The "Don't update" option is new so I couldn't have fiddled with that yet?
I triplechecked both configurations yesterday and didn't find anything that was different from what it should be. So they're fine (or I'm not seeing it ).
This happened for a couple of jobs, apparently. Looking at the timing of things, it must have been the day (April 7th) that I upgraded our Hudson from 1.351 to 1.353 and the Perforce plugin from 1.0.24 to 1.0.27. That caused a lot of quick failures because of the LineEnd-being-"null" problem, so I "immediately" downgraded the plugin to 1.0.26.
All of the "moving" builds happened around the same time of the afternoon that day, but I hadn't discovered any problems until I upgraded yesterday ... That's not to say that they weren't there, of course.
I think most, if not all, of these jobs build relatively rarely, so that could be one reason I didn't see it?
Anyway, I've kept it running on 1.354+1.0.28 overnight and it appears to be ok. I'll keep watching it, of course! torbent
added a comment - Oh, and I agree with your headache
It appears that there's not much consensus on how to run a Perforce setup. Is it the same for other SCMs, I wonder?
There has also been some changes in the plugin earlier that caused ME headaches because they changed the default behaviour. I think that was before you took charge of it - can't remember major problems recently (apart from the LineEnd).
I appreciate your work - couldn't run Hudson without it 
torbent
added a comment - Oh, and I agree with your headache
It appears that there's not much consensus on how to run a Perforce setup. Is it the same for other SCMs, I wonder?
There has also been some changes in the plugin earlier that caused ME headaches because they changed the default behaviour. I think that was before you took charge of it - can't remember major problems recently (apart from the LineEnd).
I appreciate your work - couldn't run Hudson without it torbent
added a comment - The same thing happened again!
This time I upgraded to Hudson 1.357 and Perforce plugin 1.0.29.
A build was consistently failing with Perforce problems, which was again traced to builds listed under the wrong jobs. So there's something wrong with SCM and/or workspace selection, besides the actual moving-builds-around problem.
I don't really believe the perforce plugin is to blame, but that's where I get my first indications of trouble ...
torbent
added a comment - The same thing happened again!
This time I upgraded to Hudson 1.357 and Perforce plugin 1.0.29.
A build was consistently failing with Perforce problems, which was again traced to builds listed under the wrong jobs. So there's something wrong with SCM and/or workspace selection, besides the actual moving-builds-around problem.
I don't really believe the perforce plugin is to blame, but that's where I get my first indications of trouble ... If you are absolutely sure that none of your jobs are sharing client workspaces, then I can't see how this would be the fault of the plugin. The hudson workspace is passed into the SCM plugin by hudson, so the only way it could be wrong is if hudson is messing up.
torbent
added a comment - Yes, I also think it's Hudson, or another plugin, that's messing up. I submitted this issue as JENKINS-6256 once, and have updated it with the new info. My "best" suspect is DownStreamBuildView ...
torbent
added a comment - Yes, I also think it's Hudson, or another plugin, that's messing up. I submitted this issue as JENKINS-6256 once, and have updated it with the new info. My "best" suspect is DownStreamBuildView ... 
... and while investigating just a bit further, I may have stumbled upon a much bigger problem
When I look at the last two builds listed for this job, they actually belong to that other job whose workspace is being used! So I have builds up to #283 which are correct, and then it lists 411 and 412 is builds, but they were done on the other job.
So perhaps the Perforce plugin issue here is that it uses a configuration from builds instead of the job?
Or perhaps something is really mixed up inside Hudson?
(It's not the first instances today of builds switching jobs ...)