-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Jenkins 1.596, subversion-plugin 2.5, multijob-plgin 1.16
-
Powered by SuggestiMate
Some SVN Updates work, some fail with following message:
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1265)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at com.tikal.jenkins.plugins.multijob.MultiJobBuild$MultiJobRunnerImpl.run(MultiJobBuild.java:134)
at hudson.model.Run.execute(Run.java:1759)
at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:73)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
[JENKINS-26318] Subversion Plug in 2.5 causes sporadic problems
i have same issue. do you have any svn shell commands in your job? i do "svn revert . --recursive" from command line because "svn revert before update" from subversion plugin takes too long (30 mins).
Nope, I don't. Just getting sources thanks to the Subversion plugin, and enabled "Poll SCM" in "Build Triggers"
No, I also use only the subversion plugin for updating/reverting the source code.
you may can delete tag multijob-plugin. My build fails sprodic with MatrixJob:
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1265)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Go to Subversion settings and set Subversion version to 1.8 (Configure System -> Subversion Workspace Version). Wipe out workspace and re-run job.
Wiping out the workspace and setting svn workspace to 1.8 works. But this makes the update to subversion plug in 2.5 a bit complex, because I had to wipe out all workspaces at once (or modify all jobs to do that). When the Plug in would work stable with svn workspaces 1.7, I can do this step by step.
Thanks for the tip Łukasz, unfortunately it doesn't work on my side, I still get the a similar stack:
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1265)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1718)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Same for me, also not working after set up subversion version to 1.8 and wipe out the workspace
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.plugins.templateproject.ProxySCM.checkout(ProxySCM.java:53) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) at hudson.model.Run.execute(Run.java:1718) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240)
I'm getting this too, on Jenkins ver. 1.598 with Subversion Plug-in 2.5
Same here in 1.602 SVN 2.5
14:11:27 FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
14:11:27 java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
14:11:27 at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
14:11:27 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
14:11:27 at hudson.scm.SCM.checkout(SCM.java:484)
14:11:27 at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
14:11:27 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
14:11:27 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
14:11:27 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
14:11:27 at hudson.model.Run.execute(Run.java:1750)
14:11:27 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
14:11:27 at hudson.model.ResourceController.execute(ResourceController.java:89)
14:11:27 at hudson.model.Executor.run(Executor.java:240)
Hi all,
my workaround for this issue is now to use the Naginator Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Naginator+Plugin) to retry a job if the output log contains "hudson.scm.SVNRevisionState". Attached screenshot for example. Be careful, the plugin is not working together with "Use Publisher from other Projects".
For me its not nice like this, but all the repeated jobs were ok afterwards, so it solves the problem that i have to retry manually.
Best regards
Does anyone notice this problem without BlameSubversion being installed? I recognize that the given class is provided by those two plugins and suspect classloader conflicts
$ jar tf ./plugins/subversion/WEB-INF/lib/classes.jar | grep SVNRevisionState
hudson/scm/SVNRevisionState.class
$ jar tf ./plugins/BlameSubversion/WEB-INF/lib/classes.jar | grep SVNRevisionState
hudson/scm/SVNRevisionState.class
don't know which plugin is BlameSubversion, i have the following svn plugins and still the error
Subversion Plug-in 2.5
This plugin adds the Subversion support (via SVNKit) to Jenkins.
svnmerge plugin 2.5
This plugin automates feature/personal branch workflow on Jenkins
It looks like svnmerge do not distribute: hudson/scm/SVNRevisionState.class. Could you check if there is anything else which could bring this duplication to your env?
"""
$ find ./plugins/ -name "*.jar" | xargs -ifoo jar tf foo | grep "SVNRevisionState" | sort | uniq -c
2 hudson/scm/SVNRevisionState.class
"""
I use jenkins on a windows machine, i did a text search in *.jar for SVNRevisionState:
plugins\subversion\WEB-INF\lib\classes.jar
plugins\BlameSubversion\WEB-INF\lib\classes.jar
I am using both Subversion plug-in 2.5 and Blame Upstream Committers 1.2, and both seem to be using their own hudson/scm/SVNRevisionState.class
Isn't this one a duplicate issue of https://issues.jenkins-ci.org/browse/JENKINS-27079 which has been solved?
All of these SVN error tickets are marked as resolved but the issue still persists for me.
We also have these problems if we update - so our solution was inbetween not to update
Please fix! Thankx
All of these SVN error tickets are marked as resolved but the issue still persists for me.
The resolution specified is Duplicate, which means there's already a report for it. Doesn't mean the problem was fixed.
> The resolution specified is Duplicate, which means there's already a report for it. Doesn't mean the problem was fixed.
https://issues.jenkins-ci.org/browse/JENKINS-27079 is marked as resolved, but it isn't...
https://issues.jenkins-ci.org/browse/JENKINS-27079 is marked as resolved, but it isn't...
Again, it's resolved as Duplicate. That's just how it looks in Jira. JENKINS-27079 duplicates JENKINS-26734, which in turn duplicates JENKINS-26303. And in the issue comments there, rodrigc wrote:
I released version 0.4 of the Multiple SCMs plugin, so you can give that a try and report back here if it fixes your problem.
So I'm fairly sure that is the correct place to report any issues.
I'm experiencing this bug on almost every other build of seemingly un-related jobs. I followed the workaround suggested by Łukasz Koniecki to adjust my working copy format to 1.8 and recreate the workspace, but this doesn't seem to work for every job.
I'm running Jenkins 1.617, subversion-plugin version 2.5:
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1282) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1744) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374)
It's a big problem for my current configuration, I'm close to attempting a downgrade to 2.4.5 of the subversion-plugin. Please let me know if there's any more information I can provide for this issue.
Yes it would be great if this issue get fixed. This issue is affecting automation. Please give better priority to fix this issue
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
We have the same issue. No MultipleSCM plugin installed and every single svn checkout failed with the reported error message. Sadly we have to use the new plugin because of the new SVN format of Subversin 1.8.
Please fix this.About 130 Jobs are failing because of this permanently. No workaround from above is working.
This can be caused by duplicate class name (hudson.scm.SVNRevisionState) between subversion-plugin and other plugins, for example BlameSubversion-plugin.
True, it looks like BlameSubversion actually has another class of the same name. Clearly a terrible idea.
hudson.scm.SVNRevisionState in subversion-plugin used to be a private class but that was changed in this commit:
commit 75080db63a30d42ac66d5ff46f8fbf49bab6b637
Author: Nicolas De loof <nicolas.deloof@gmail.com>
Date: Thu Oct 30 09:41:43 2014 +0100
Make SVNRevisionState public
Required so another plugin can retrieve the built revision. Typical use case is svnmerge-plugin which has to merge built revision to upstream branch
I updated to the latest version and the issue is still there
At revision 3327
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:726)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:861)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:408)
Finished: FAILURE
Assigning to BlameSubversion plugin after no response to previous comment.
Since i deactivated the BlameSubversion plugin, no more errors occured. So for me it seems its related to it.
jenkins_mizuho What makes you think this is unrelated to BlameSubversion?
we removed the BlameSubversion plugin and we still see the same error.
Maybe some other plugin contains conflicting SVNRevisionState class?
On Linux you can run this to check if you have such a plugin (assuming Jenkins is in /var/lib/jenkins/):
for i in $(find /var/lib/jenkins/plugins/ -name '*.jar') ; do ( unzip -l $i | grep -q SVNRevisionState ) && echo $i ; done
Why do you think this issue has anything to do with the BlameSubversion plugin? If GitHub is right, the BlameSubversion project has no changes for 3 years. BlameSubversion also does not seem to do any custom class loading.
For
hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
to occur, it is not necessary that there are two different class files with name hudson.scm.SVNRevisionState. It suffices that the same class is being loaded from the same file by two different class loaders.
So the cause of the error might also be in the Subversion plugin or in Jenkins itself.
Why do you think this issue has anything to do with the BlameSubversion plugin? If GitHub is right, the BlameSubversion project has no changes for 3 years. BlameSubversion also does not seem to do any custom class loading.
Because it's a terrible idea to copy a class from another plugin, as that sets you up for trouble like this. Since Subversion plugin's existed first, BlameSubversion is the copy, and hence (no pun intended) to blame.
Why do you think this issue has anything to do with the BlameSubversion plugin? If GitHub is right, the BlameSubversion project has no changes for 3 years. BlameSubversion also does not seem to do any custom class loading.
Because the problem doesn't appear with a custom version of BlameSubversion plugin where I've renamed SVNRevisionState class from BlameSubversion plugin to BlameSVNRevisionState.
If anybody's interested the modified version of the plugin is here - https://github.com/ezjenkins/BlameSubversion-plugin
I created PR 1 a while ago to provide compatibility with the blame subversion plugin, and svnkit 1.8.
I hope they will do test\check\merge on your pull request as soon as possible.
I have had this issue for over 2 years (cannot be cast error) in my production Jenkins. Over the Christmas break I did a update to the latest Java and Jenkins and all plugins, and finally found that this was the cause of the issue. Does someone have a .jpi file with this fix available? (from https://github.com/ezjenkins/BlameSubversion-plugin)
- Or pointers on instructions to create the plugin? I tried building from: https://github.com/ezjenkins/BlameSubversion-plugin.git, no luck yet. That made a '.hpl' file that I assume is for Hudson, not Jenkins.
.hpi file works with Jenkins as well.
Btw, I stopped using this plug-in altogether about half a year ago. I don't remember what was the exact reason but it was still causing problems even with the patches.
sbade hpi works in Jenkins by default. Try to install your hpi file via "Manage Jenkins \ Manage Plugins \ Advanced \ Upload Plugin"
Thanks for the tips! I found that my downstream jobs can still send emails to culprits without this plugin - the upstream build launches several downsream test jobs with the parameterized trigger plugin with the option to pass SVN revisions. I still would like an EVN var in the downstream job to print the SVN revision, but this is working. I may try this plugin again when it is more stable.
This plugin is a great idea but it would be nice to have some kind of stability info in the plugin index that to help people avoid trouble. This might be hard to manage though.
My last comment about passing SVN revisions turned out to not work after all.
For my flow I do need this plugin. (build job launches multiple test jobs, test jobs update to the same SVN revision and sends emails to culprits)
My flow is fixed now - I did a build (mvn package) using source from https://github.com/ezjenkins/BlameSubversion-plugin.git
Thanks for the fix!
If this helps anyone I put a copy of my build's .hpi file at:
http://solidcode.org/downloads/BlameSubversion.hpi
(sorry - website is very out of date).
Hopefully the official plugin will be fixed soon.
Facing the same issue, though I don't have MultiJob plug in installed, so this is not an interoperability issue.
Reverted back Subversion Plugin to v2.4.5.