Re: [cross-project-issues-dev] Hudson job keeps rebuilding
I'm having exactly the opposite problem - my hudson jobs keep aborting: [INFO] Resolving target platform for project MavenProject: org.eclipse.bpmn2.modeler:org.eclipse.bpmn2.modeler.core:0.0.1-SNAPSHOT @ /opt/users/hudsonbuild/workspace/tycho-bpmn2modeler-0.0.1-nightly/org.eclipse.bpmn2.modeler.core/pom.xml [ERROR] Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update - [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:103) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:85) at org.eclipse.tycho.p2.repository.DefaultTychoRepositoryIndex.read(DefaultTychoRepositoryIndex.java:76) at org.eclipse.tycho.p2.repository.FileBasedTychoRepositoryIndex.createRepositoryIndex(FileBasedTychoRepositoryIndex.java:46) at org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.init(ResolutionContextImpl.java:142) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:32) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:1) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:156) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) Is this a maven repo problem and, if so, how do I fix it? Thanks! Bob - Original Message - I'm seeing the same thing. The build page says there were No changes. Checking the polling log, I see: Started on Feb 26, 2012 3:01:15 AM Using strategy: Default [poll] Last Build : #255 [poll] Last Built Revision: Revision d39f64adfb1570f6be9f07a636d4d2a1bf781562 (origin/cdt_8_0) Last build was not on tied node, forcing rebuild. Done. Took 3.1 sec Changes found forcing rebuild is probably the key. Is everyone seeing the same? What does not on tied node mean? Doug. On Sun, Feb 26, 2012 at 12:21 PM, David M Williams david_willi...@us.ibm.com wrote: I know there was a problem where a Gerrit Plugin was triggering jobs (unrelated to Gerrit) but as far as I know, that was disabled/removed from the production Hudson system. (Sorry, don't know bug number). Plus, I had a case where URL Content Change trigger stopped working right, and those jobs were building over and over again, even though no content change (bug 363891 [1]). In the past, I've sometimes found it helps odd Hudson behavior to wipe out workspace, essentially resetting what ever is there. To get to that option, click on the job, click on Workspace (on left, upper part of page), which displays the workspace, but also reveals a Wipe out workspace option. I'm sure it is mostly superstitious behavior ... but has seemed to help in some cases. In any case, I'd encourage you see if any existing bugs are related to your observations [2] and if not, to open one [3] being sure to make note it is on Eclipse Infrastructure. Good luck, [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=363891 [2] https://bugs.eclipse.org/bugs/query.cgi?classification=Technologyproduct=Hudsonquery_format=advanced [3] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Hudson From: Eike Stepper step...@esc-net.de To: cross-project-issues-dev@eclipse.org, Date: 02/25/2012 10:58 PM
Re: [cross-project-issues-dev] Hudson job keeps rebuilding
2012/2/27 Bob Brodt bbr...@redhat.com I'm having exactly the opposite problem - my hudson jobs keep aborting: [INFO] Resolving target platform for project MavenProject: org.eclipse.bpmn2.modeler:org.eclipse.bpmn2.modeler.core:0.0.1-SNAPSHOT @ /opt/users/hudsonbuild/workspace/tycho-bpmn2modeler-0.0.1-nightly/org.eclipse.bpmn2.modeler.core/pom.xml [ERROR] Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update - [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:103) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:85) at org.eclipse.tycho.p2.repository.DefaultTychoRepositoryIndex.read(DefaultTychoRepositoryIndex.java:76) at org.eclipse.tycho.p2.repository.FileBasedTychoRepositoryIndex.createRepositoryIndex(FileBasedTychoRepositoryIndex.java:46) at org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.init(ResolutionContextImpl.java:142) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:32) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:1) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:156) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) Is this a maven repo problem and, if so, how do I fix it? I think this is caused by https://bugs.eclipse.org/bugs/show_bug.cgi?id=347963 see this recent email on the tycho-user list http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02020.html -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson job keeps rebuilding
Thanks Matthias, but I can't figure out the workaround. Where does hudson create the .m2/repository? Is this something I can fix from an ssh shell or do I need to send a request to webmaster? - Original Message - 2012/2/27 Bob Brodt bbr...@redhat.com I'm having exactly the opposite problem - my hudson jobs keep aborting: [INFO] Resolving target platform for project MavenProject: org.eclipse.bpmn2.modeler:org.eclipse.bpmn2.modeler.core:0.0.1-SNAPSHOT @ /opt/users/hudsonbuild/workspace/tycho-bpmn2modeler-0.0.1-nightly/org.eclipse.bpmn2.modeler.core/pom.xml [ERROR] Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update - [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.IllegalArgumentException: Invalid portable string: p2.osgi.bundle:org.eclipse.update at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:103) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:85) at org.eclipse.tycho.p2.repository.DefaultTychoRepositoryIndex.read(DefaultTychoRepositoryIndex.java:76) at org.eclipse.tycho.p2.repository.FileBasedTychoRepositoryIndex.createRepositoryIndex(FileBasedTychoRepositoryIndex.java:46) at org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.init(ResolutionContextImpl.java:142) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:32) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:1) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:156) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) Is this a maven repo problem and, if so, how do I fix it? I think this is caused by https://bugs.eclipse.org/bugs/show_bug.cgi?id=347963 see this recent email on the tycho-user list http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02020.html -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson job keeps rebuilding
David, I already announced the solution (pasted it here again), I'm waiting for the webmaster to fix it. We have two options - Change the label of the node hudson-slave1 to hudson-slave1 (currently it is hudson-slave2). Then change those jobs which are tied to the label hudson-slave2 to hudson-slave1 - Leave the label of the node hudson-slave1 as hudson-slave2, but change all those jobs which are tied to the label hudson-slave1 to hudson-slave2 I think options 1 is easier because only three jobs are tied to the label hudson-slave2, but more than 35 jobs are tied to the label hudson-slave1. - Also since this require reboot, it would help if the job owners fix their jobs with the other two suggestions I made earlier. - Specify in the job to retain only about 15-20 old builds - Reduce the amount of standard output (debug trace etc) in JUnit tests With that done, along with the NFS change, I expect better performing hudson. - Winston On 2/27/12 9:27 AM, David M Williams wrote: If you are interested to know the reason (lengthy read though) here is the note I shared with Matt and Denis. Thanks for sharing the information. It seems very significant (little that I understand it). I would encourage you to open/track such issues in bugzilla, as it makes it easier to track progress and provides a better long-term record of what's happened, what was changed, etc. Though communication here is good too, and sounds like at some point you'll need to announce the solution and who has to change what. Greatest thanks, From: Winston Prakashwinston.prak...@gmail.com To: Cross project issuescross-project-issues-dev@eclipse.org, Date: 02/26/2012 03:06 PM Subject:Re: [cross-project-issues-dev] Hudson job keeps rebuilding Sent by:cross-project-issues-dev-boun...@eclipse.org I was also baffled by this repeated building. Initially we thought it was because of Gerrit plugin. After couple of days of pouring through everything, finally found out the reason. I discussed the reason and possible solution with Matt and Denis. Hopefully we could fix this next week. If you are interested to know the reason (lengthy read though) here is the note I shared with Matt and Denis. When you tie a job to a slave configuration, in the configuration file following is written assignedNodehudson-slave1/assignedNode When a build finishes, a file is createdjob/builds/build-no/build.xml. This file has builtOnhudson-slave1/builtOn When Git plugin does a polls, it first checks what node the job is tied to (in this case hudson-slave1) and then checks which node the last build happened (in this case it is again hudson-slave1). If the builtOn node is not same as assignedNode, then Git poll triggers a build. Strangely Git plugin still triggers the build even though both are same. I wrote a small Groovy script to verify both are same. See below the object ( @5301ca0c) and the display name are same. I noticed one odd thing. If you see the label I printed out above it says hudson-slave1 which belongs to the node hudson-slave1. Strangely, the node hudson-slave1 has two labels build2 and hudson-slave2. There is no such label hudson-slave1 (see the first picture). However, if I look at nodes tied to to label hudson-slave1, it shows the corresponding node as hudson-slave1. This is really odd, because there is no such label. Coincidentally all these jobs which are going crazy and doing repeated builds belong to the mysterious label hudson-slave1, which in fact doesn't exists. I changed the tied label of one of the job to hudson-slave2 which is the label for the node hudson-slave1 and it stopped building repeatedly. Appears the labels of the nodes are messed up. If we clean up this mess, all those jobs going crazy will get back its sanity. We have two options to clean up the mess - Change the label of the node hudson-slave1 to hudson-slave1 (currently it is hudson-slave2). Then change those jobs which are tied to the label hudson-slave2 to hudson-slave1 - Leave the label of the node hudson-slave1 as hudson-slave2, but change all those jobs which are tied to the label hudson-slave1 to hudson-slave2 I think options 1 is easier because only three jobs are tied to the label hudson-slave2, but more than 35 jobs are tied to the label hudson-slave1. BTW, this also requires a Hudson restart and the good news is we can put back Gerrit plugin, because it seems it has nothing to do with the repeated build. - Winston On 2/26/12 9:35 AM, Doug Schaefer wrote: I'm seeing the same thing. The build page says there were No changes. Checking the polling log, I see: Started on Feb 26, 2012 3:01:15 AM Using strategy: Default [poll] Last Build : #255 [poll] Last Built Revision: Revision d39f64adfb1570f6be9f07a636d4d2a1bf781562 (origin/cdt_8_0) Last build was not on tied node, forcing rebuild. Done. Took 3.1 sec
