I'm not sure about this, but in my opinion it's a bug that change
information is lost when a build fails during scm checkout.
Can you open a JIRA issue for this - and better first check if there's
already an existing issue for this?
thanks
Christoph
Am 29.11.2012 09:37, schrieb Ihar Kudraŭcaŭ:
For example, I have a job and its results are below:
build5 - successful (change5 in SCM)
build4 - failed (chaneg4 in SCM)
build3 - failed (change3 in SCM)
build2 - failed when code was checkouting from subversion (change2 in SCM)
build1 - successful (change1 in SCM)
When I get changeset of build4 or build5 I can see change4 or change5.
When I get changeset of build2 I see nothing and it's normal. But
build2 didn't create revision.txt and If I get changeset of build3 I
expect to see change3 + change2, but I see nothing too. Change2 and
change3 dissappeared for jenkins completely.
I looked to source code of subversion plugin and saw method
parseRevisionFile. This method has parameter findClosest.
All what I need is previousRevisions property assignment with
findClosest=true instead of findClosest=false.
So I've replaced assignment from
previousRevisions =
SubversionSCM.parseRevisionFile(build.getPreviousBuild());
to
previousRevisions =
SubversionSCM.parseRevisionFile(build.getPreviousBuild(), true, false);
rebuilt plugin and it's work for me.
But I have questions: Is it a right way to lose any change
information? Why is findClosest=false by default? Are there any
problem with findClosest=true? Are there ways for use subversion
plugin with findClosest=true without rebuilding plugin?
Thanks in advance.
