[
https://issues.jenkins-ci.org/browse/JENKINS-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163643#comment-163643
]
Patrick Lemmens commented on JENKINS-6256:
------------------------------------------
We have experienced the same issue and this has been corrupting our build
history for quite some time... :-(
We also have experienced very strange symptoms because of this when the build
number in a wrongly filed build folder was higher than the highest build number
of the job; the workspace would either appear empty or it would show the
workspace of the other job... Then CVS polling would go haywire and decide the
job needed rebuilding as the workspace would be empty or contain the wrong
code...
Only just found this bug report. Can it please be assigned to someone and fixed
with high priority?
We are still on Hudson 1.395 and hope to move to Jenkins 1.447.1 LTS soon.
> Builds are listed under the wrong job
> -------------------------------------
>
> Key: JENKINS-6256
> URL: https://issues.jenkins-ci.org/browse/JENKINS-6256
> Project: Jenkins
> Issue Type: Bug
> Components: downstream-buildview
> Environment: Hudson 1.354 (?)
> Reporter: torbent
> Priority: Critical
>
> This started over in JENKINS-6254, but I think it's not limited to Perforce,
> so I'm submitting this in Core.
> Today, after upgrading to 1.354, I'm seeing cases where builds move from
> their job into other jobs instead. In JENKINS-6254 I note one case where two
> builds (412+413) from one job move to another job, and possibly cause the
> Perforce plugin to get very confused about where to build.
> Earlier I had two jobs where 3 builds from each had switched sides and now
> were listed as belonging to the other job.
> The switching was complete in the sense that the build directories on the
> Hudson server were in the wrong places. I stopped the service and moved the
> directories around, and they looked fine again.
> One of the those jobs consistently failed like this:
> {noformat}
> FATAL: null
> java.lang.NullPointerException
> at hudson.tasks.ArtifactArchiver.prebuild(ArtifactArchiver.java:147)
> at
> hudson.model.AbstractBuild$AbstractRunner.preBuild(AbstractBuild.java:595)
> at
> hudson.model.AbstractBuild$AbstractRunner.preBuild(AbstractBuild.java:590)
> at
> hudson.model.AbstractBuild$AbstractRunner.preBuild(AbstractBuild.java:586)
> at hudson.model.Build$RunnerImpl.doRun(Build.java:114)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
> at hudson.model.Run.run(Run.java:1244)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:122)
> {noformat}
> I'm not really keen on going through all our jobs to scan for switched
> builds, so I'll likely have to downgrade to 1.353.
> A curious thing, though, is that all of the switched jobs (so far) took place
> April 7th (a week ago). We were not running 1.354 then, but I didn't see the
> problems that I do now, so I'm mostly inclined to believe that it's something
> to do with 1.354.
> After downgrading, I cannot really be of much help as we don't have a
> "testing" server (but I'm beginning to think we should).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
