[JIRA] [findbugs] (JENKINS-18394) IncompatibleClassChangeError after upgrade to 1.519
Chris Lee commented on JENKINS-18394 IncompatibleClassChangeError after upgrade to 1.519 Cleaned the slave (wiped out the entire home directory, as if it was a new ssh-slave), with no effect. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [findbugs] (JENKINS-18394) IncompatibleClassChangeError after upgrade to 1.519
Chris Lee created JENKINS-18394 IncompatibleClassChangeError after upgrade to 1.519 Issue Type: Bug Affects Versions: current Assignee: Ulli Hafner Components: findbugs Created: 18/Jun/13 10:31 PM Description: Below exception occurs on every build following upgrade to 1.519: [FINDBUGS] Collecting findbugs analysis files... ERROR: Publisher hudson.plugins.findbugs.FindBugsPublisher aborted due to exception hudson.util.IOException2: remote file operation failed: /data/jenkins/workspace/EMR_450 at hudson.remoting.Channel@15f6059:devbuild01 at hudson.FilePath.act(FilePath.java:901) at hudson.FilePath.act(FilePath.java:878) at hudson.plugins.findbugs.FindBugsPublisher.perform(FindBugsPublisher.java:161) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:146) at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:331) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726) at hudson.model.Run.execute(Run.java:1618) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:242) Caused by: java.io.IOException: Remote call on devbuild01 failed at hudson.remoting.Channel.call(Channel.java:731) at hudson.FilePath.act(FilePath.java:894) ... 13 more Caused by: java.lang.IncompatibleClassChangeError: Implementing class at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:705) at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch3(RemoteClassLoader.java:759) at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) at
[JIRA] [findbugs] (JENKINS-18394) IncompatibleClassChangeError after upgrade to 1.519
Chris Lee commented on JENKINS-18394 IncompatibleClassChangeError after upgrade to 1.519 ...downgrading to 1.518 resolves the issue. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee commented on JENKINS-13844 Emulate clean checkout by... does not work with 1.7 subversion repositories No. There is more to this issue than just the ignored files. Here's a test case from a simple Jenkins / SVN (Jenkins 1.483, SVN 1.7): After wiping out the workspace and running an initial build: [root@devemr01 UTIL_TRUNK]# ll total 24 drwxrwxr-x 10 jenkins jenkins 4096 Sep 30 00:06 build -rw-rw-r-- 1 jenkins jenkins 376 Sep 30 00:06 build.gradle drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 lib drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 releng -rw-rw-r-- 1 jenkins jenkins 37 Sep 30 00:06 settings.gradle drwxrwxr-x 4 jenkins jenkins 4096 Sep 30 00:06 src ...adding an unversioned file: [root@devemr01 UTIL_TRUNK]# touch foo [root@devemr01 UTIL_TRUNK]# svn status ? foo Running the job (note that the unversioned file wasn't detected or removed): 00:07:59 Cleaning up /home/jenkins/workspace/UTIL_TRUNK/. 00:07:59 Updating svn://svn.ma.net/util/trunk to revision '2012-09-30T00:07:58.927 -0700' 00:07:59 At revision 38394 ...and the unversioned file, and the ignored dir 'build', are still present: [root@devemr01 UTIL_TRUNK]# ll total 24 drwxrwxr-x 10 jenkins jenkins 4096 Sep 30 00:06 build -rw-rw-r-- 1 jenkins jenkins 376 Sep 30 00:06 build.gradle -rw-r--r-- 1 rootroot 0 Sep 30 00:07 foo drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 lib drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 releng -rw-rw-r-- 1 jenkins jenkins 37 Sep 30 00:06 settings.gradle drwxrwxr-x 4 jenkins jenkins 4096 Sep 30 00:06 src [root@devemr01 UTIL_TRUNK]# It appears that the SVNKit 'status' API call is working differently (and possibly incorrectly) for SVN 1.7 repositories. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee
commented on JENKINS-13844
Emulate clean checkout by... does not work with 1.7 subversion repositories
Found the issue; the status objects returned by SVNKit have different values when used against a SVN 1.7 working copy.
Using the original snippet of code, status objects are returned for the correct files, but their status is STATUS_NONE, and hence the subsequent logic for removing files of specific statuses is not triggered:
/home/jenkins/workspace/UTIL_TRUNK/.gradlenone
/home/jenkins/workspace/UTIL_TRUNK/foonone
/home/jenkins/workspace/UTIL_TRUNK/build none
Modifying the code to combine the node contents status yields the correct results:
/home/jenkins/workspace/UTIL_TRUNK/.gradle ignored
Deleting /home/jenkins/workspace/UTIL_TRUNK/.gradle
/home/jenkins/workspace/UTIL_TRUNK/foo unversioned
Deleting /home/jenkins/workspace/UTIL_TRUNK/foo
/home/jenkins/workspace/UTIL_TRUNK/build ignored
The relevant change is:
// for SVN 1.7 working copies, status.getContentsStatus() is STATUS_NONE; need to use the combined status to get the correct status (UNVERSIONED, IGNORED, etc.)
SVNStatusType s = status.getCombinedNodeAndContentsStatus();
//SVNStatusType s = status.getContentsStatus();
The complete test harness is:
import java.io.File;
import java.util.*;
import org.tmatesoft.svn.core.SVNDepth;
import org.tmatesoft.svn.core.SVNException;
import org.tmatesoft.svn.core.wc.ISVNStatusHandler;
import org.tmatesoft.svn.core.wc.SVNClientManager;
import org.tmatesoft.svn.core.wc.SVNStatus;
import org.tmatesoft.svn.core.wc.SVNStatusType;
import org.tmatesoft.svn.core.wc.*;
import org.tmatesoft.svn.core.internal.wc.*;
public class Test
{
public static void main( String[] args ) throws SVNException
{
SVNClientManager clientManager = SVNClientManager.newInstance();
CollectionString changeLists = Collections.emptyList();
//clientManager.getStatusClient().doStatus( new File( args[ 0 ] ).getAbsoluteFile(), SVNRevision.WORKING, SVNDepth.INFINITY, false, false, true, false, new ISVNStatusHandler()
clientManager.getStatusClient().doStatus( new File( args[ 0 ] ), null, SVNDepth.INFINITY, false, false, true, false, new ISVNStatusHandler()
{
@Override
public void handleStatus( SVNStatus status ) throws SVNException
{
// for SVN 1.7 working copies, status.getContentsStatus() is STATUS_NONE; need to use the combined status to get the correct status (UNVERSIONED, IGNORED, etc.)
SVNStatusType s = status.getCombinedNodeAndContentsStatus();
//SVNStatusType s = status.getContentsStatus();
System.out.printf( "%-60s %s\n", status.getFile(), s );
if( s == SVNStatusType.STATUS_UNVERSIONED || s == SVNStatusType.STATUS_IGNORED || s == SVNStatusType.STATUS_MODIFIED )
{
System.out.println( "Deleting " + status.getFile() );
}
}
}, null );
}
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13859) Emulate clean check out seems to fail after upgrading to v1.4 of subversion plugin
Chris Lee commented on JENKINS-13859 Emulate clean check out seems to fail after upgrading to v1.4 of subversion plugin The solution for this (requires a code change) is detailed in JENKINS-13844 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee commented on JENKINS-13844 Emulate clean checkout by... does not work with 1.7 subversion repositories This is caused by changes in SVN 1.7 relating to ignored files - they are no longer reported by default in 'svn status' (the SVNKit API used by Jenkins mirrors this behaviour). In the workspace for a Jenkins project (after the job has run), no changes are shown: [root@devemr01 UTIL_TRUNK]# svn status However, the below command shows files/directories that are marked as ignored: [root@devemr01 UTIL_TRUNK]# svn status --no-ignore I .gradle I build ...and creating a new file that isn't ignored shows up in 'svn status': [root@devemr01 UTIL_TRUNK]# touch foo [root@devemr01 UTIL_TRUNK]# svn status ? foo UpdateWithCleanUpdater.java needs to explicitly request that SVNKit include 'ignored' files such that they can be deleted. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee
commented on JENKINS-13844
Emulate clean checkout by... does not work with 1.7 subversion repositories
Code from UpdateWithCleanUpdater.java:
clientManager.getStatusClient().doStatus(local, null, SVNDepth.INFINITY, false, false, true, false, new ISVNStatusHandler() {
public void handleStatus(SVNStatus status) throws SVNException {
SVNStatusType s = status.getContentsStatus();
if (s == SVNStatusType.STATUS_UNVERSIONED || s == SVNStatusType.STATUS_IGNORED || s == SVNStatusType.STATUS_MODIFIED) {
listener.getLogger().println("Deleting "+status.getFile());
try {
File f = status.getFile();
if (f.isDirectory())
hudson.Util.deleteRecursive(f);
else
f.delete();
} catch (IOException e) {
throw new SVNException(SVNErrorMessage.create(SVNErrorCode.UNKNOWN, e));
}
}
}
}, null);
...the fifth parameter is 'includeIgnored' which is strangely set to false (and always has been), although the subsequent code expects ignored elements. Guessing that the inclusion of 'ignored' files was a bug with previous SVN (and SVNKit) versions that Jenkins inadvertently relied on.
SVNKit API: http://svnkit.com/javadoc/org/tmatesoft/svn/core/wc/SVNStatusClient.html#doStatus(java.io.File, org.tmatesoft.svn.core.wc.SVNRevision, org.tmatesoft.svn.core.SVNDepth, boolean, boolean, boolean, boolean, org.tmatesoft.svn.core.wc.ISVNStatusHandler, java.util.Collection)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
