[JIRA] (JENKINS-15620) Can't start Emulator with Android SDK 20.0.3
Stefan T created JENKINS-15620 Can't start Emulator with Android SDK 20.0.3 Issue Type: Bug Affects Versions: current Assignee: Christopher Orr Components: android-emulator Created: 25/Oct/12 6:50 AM Description: This seems to be a new version of JENKINS-14497 and JENKINS-15097. I get this error since we updated the android sdk: java.lang.NumberFormatException: For input string: "20.0.3" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:458) at java.lang.Integer.parseInt(Integer.java:499) at hudson.plugins.android_emulator.util.Utils$2.call(Utils.java:187) at hudson.plugins.android_emulator.util.Utils$2.call(Utils.java:156) at hudson.remoting.LocalChannel.call(LocalChannel.java:45) at hudson.plugins.android_emulator.util.Utils.getAndroidSdk(Utils.java:197) at hudson.plugins.android_emulator.AndroidEmulator.setUp(AndroidEmulator.java:225) at hudson.model.Build$BuildExecution.doRun(Build.java:154) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1488) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Jenkins ver. 1.474 Plugin-Version: 2.6 (updated yesterday) Project: Jenkins Priority: Major Reporter: Stefan T 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-15499) HistoryWidget/entry.jelly throws NullPointerException
Thomas Oeding commented on JENKINS-15499 HistoryWidget/entry.jelly throws NullPointerException the same for 1.487 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-15619) Huge Files sync eat all the Java memory and make very long gc
sh j commented on JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc Thank you very much. I will check it!!! 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-15619) Huge Files sync eat all the Java memory and make very long gc
Rob Petti resolved JENKINS-15619 as Cannot Reproduce Huge Files sync eat all the Java memory and make very long gc Change By: Rob Petti (25/Oct/12 4:27 AM) Status: Open Resolved Resolution: Cannot Reproduce 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-15619) Huge Files sync eat all the Java memory and make very long gc
Rob Petti commented on JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc Wow, that's really old... This was fixed back in 1.3.13, I believe, but I highly recommend updating to the latest. 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-15619) Huge Files sync eat all the Java memory and make very long gc
sh j commented on JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc we use 1.1.13 now. which version was this problem solved from ? 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-15617) does not work inside
dogfood commented on JENKINS-15617 does not work inside Integrated in jenkins_main_trunk #2030 JENKINS-15617 (Revision 5aca73f1831f7895220e7c869cfb13e6c2db131a) Result = UNSTABLE kohsuke : 5aca73f1831f7895220e7c869cfb13e6c2db131a Files : war/src/main/webapp/scripts/hudson-behavior.js 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-15341) New workflow creation should be in the form validation
Max Spring resolved JENKINS-15341 as Fixed New workflow creation should be in the form validation Added a button to the "eror" message to create the workflow. A non-existing workflow won't be created automatically any more. Change By: Max Spring (25/Oct/12 2:40 AM) Status: In Progress Resolved Resolution: Fixed 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-15341) New workflow creation should be in the form validation
Max Spring commented on JENKINS-15341 New workflow creation should be in the form validation Added a button to the "error" message to create the workflow. A non-existing workflow won't be created automatically any more. 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-15341) New workflow creation should be in the form validation
SCM/JIRA link daemon commented on JENKINS-15341 New workflow creation should be in the form validation Code changed in jenkins User: Max Spring Path: jenkow-plugin/src/main/java/com/cisco/step/jenkins/plugins/jenkow/JenkowBuilder.java http://jenkins-ci.org/commit/jenkow-plugin/ac27f4cd4ebc0f1e912dbdf717d42a30634ccb68 Log: fixed JENKINS-15341 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-15502) Email-ext issues: attachments feature creating issues
hiteswar kumar updated JENKINS-15502 Email-ext issues: attachments feature creating issues please find attached config.xml for your reference and reproducing error: ERROR: Could not send email as a part of the post-build publishers. Can you please share your comment as soon as possible. Change By: hiteswar kumar (25/Oct/12 2:39 AM) Attachment: config.xml 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-15619) Huge Files sync eat all the Java memory and make very long gc
Rob Petti assigned JENKINS-15619 to Rob Petti Huge Files sync eat all the Java memory and make very long gc Change By: Rob Petti (25/Oct/12 2:39 AM) Assignee: Rob Petti 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-15619) Huge Files sync eat all the Java memory and make very long gc
Rob Petti commented on JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc It's already limited, and most of the log is thrown out immediately rather than stored for that very reason. What version of the perforce plugin are you using? I've synced millions of files at once without any issues. 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-15341) New workflow creation should be in the form validation
Max Spring started work on JENKINS-15341 New workflow creation should be in the form validation Change By: Max Spring (25/Oct/12 2:28 AM) Status: Open In Progress 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-3070) Uninstaller for plugins
Bao Xiaopan(Bob) commented on JENKINS-3070 Uninstaller for plugins It's a great update!!! 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-15617) does not work inside
dogfood commented on JENKINS-15617 does not work inside Integrated in jenkins_main_trunk #2029 [FIXED JENKINS-15617] (Revision 51f508ba371ee222dced304c4a77a9b1b4ca37db) Result = UNSTABLE kohsuke : 51f508ba371ee222dced304c4a77a9b1b4ca37db Files : war/src/main/webapp/scripts/hudson-behavior.js 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-15617) does not work inside
SCM/JIRA link daemon commented on JENKINS-15617 does not work inside Code changed in jenkins User: Kohsuke Kawaguchi Path: war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/5aca73f1831f7895220e7c869cfb13e6c2db131a Log: JENKINS-15617 This needs to be eval, not geval. Plus I forgot to return the value. 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-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed
Yimin Li commented on JENKINS-9104 Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed Is it possible to add the workaround to the next Jenkins release and solve the problem later? 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-15619) Huge Files sync eat all the Java memory and make very long gc
sh j created JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc Issue Type: Bug Assignee: Unassigned Components: perforce Created: 25/Oct/12 1:41 AM Description: With really huge Files sync the p4 plugin can run out of java heap space and it make long gc. At least it looks like the reason for memory problems would be huge file sync logs when file syncing. An example case: Start 50+ builds same time ( a sync include 40+ files ) Our 200G heap exhausted in 3 min and make very long gc. Maybe there should be an option to limit the amount of sync log that p4 plugin keep while syncing? Now we are limiting simultaneously over 20 p4 sync manually. plz help me. Project: Jenkins Priority: Major Reporter: sh j 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-15619) Huge Files sync eat all the Java memory and make very long gc
sh j updated JENKINS-15619 Huge Files sync eat all the Java memory and make very long gc Change By: sh j (25/Oct/12 1:42 AM) Description: With really huge Files sync the p4 plugin can run out of java heap space and it make long gc. At least it looks like the reason for memory problems would be huge file sync logs when file syncing. An example case:Start 50+ builds same time ( a sync include 40+ files )Our 200G heap exhausted in 3 min and make very long gc.Maybe there should be an option to limit the amount of sync log that p4 plugin keep while syncing?Now we are limiting simultaneously over 20 p4 sync manually. plz help me. 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-15341) New workflow creation should be in the form validation
Max Spring stopped work on JENKINS-15341 New workflow creation should be in the form validation Change By: Max Spring (25/Oct/12 1:40 AM) Status: In Progress Open 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-15617) does not work inside
Jesse Glick assigned JENKINS-15617 to Kohsuke Kawaguchi does not work inside Change By: Jesse Glick (25/Oct/12 1:04 AM) Assignee: Jesse Glick Kohsuke Kawaguchi 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-15617) does not work inside
Jesse Glick commented on JENKINS-15617 does not work inside Simpler still: 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-15617) does not work inside
Jesse Glick commented on JENKINS-15617 does not work inside is actually necessary as the workaround for the first part; otherwise you sometimes get errors in the page like Cannot call method 'select' of undefined since Prototype exists but has no member Selector. 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-15617) does not work inside
SCM/JIRA link daemon resolved JENKINS-15617 as Fixed does not work inside Change By: SCM/JIRA link daemon (25/Oct/12 12:42 AM) Status: Open Resolved Resolution: Fixed 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-15617) does not work inside
SCM/JIRA link daemon commented on JENKINS-15617 does not work inside Code changed in jenkins User: Kohsuke Kawaguchi Path: war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/51f508ba371ee222dced304c4a77a9b1b4ca37db Log: [FIXED JENKINS-15617] Evaluate script in global context. See http://perfectionkills.com/global-eval-what-are-the-options/ for how to evaluate _javascript_ in global context. 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-15617) does not work inside
Jesse Glick commented on JENKINS-15617 does not work inside The latter problem is not quite true:
[JIRA] (JENKINS-15439) Jenkins build records lazy-loading failed to load some of my jobs.
Jose Sa commented on JENKINS-15439 Jenkins build records lazy-loading failed to load some of my jobs. I'm still getting problems loading jobs after LazyLoading feature introduction. I've added my symptoms in JENKINS-15533 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-15617) does not work inside
Jesse Glick updated JENKINS-15617 does not work inside Demo: hpi:run; create job; add demo builder; click Test; nothing happens. Save job (with builder), Configure again; now Test works. Change By: Jesse Glick (25/Oct/12 12:05 AM) Attachment: JENKINS-15617.zip 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-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Jose Sa commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 With 1.487 I still have same problem (i'm keeping 1.484 until LazyLoading gets fixed) Oct 25, 2012 12:49:19 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading job some_job_name java.lang.NullPointerException at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:432) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:574) at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:240) at java.util.AbstractMap$2$1.(AbstractMap.java:378) at java.util.AbstractMap$2.iterator(AbstractMap.java:377) at hudson.util.RunList.iterator(RunList.java:103) at org.jvnet.hudson.plugins.DownStreamProjectActionFactory.createFor(DownStreamProjectActionFactory.java
[JIRA] (JENKINS-13754) Error when compiling a plugin against jenkins version 1.463
Kohsuke Kawaguchi commented on JENKINS-13754 Error when compiling a plugin against jenkins version 1.463 I had the same issue with IntelliJ. In my case, from the project setting, "Compiler > Annotation Processors > Enable annotation processing" fixed the problem (but I don't know why.) 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-15341) New workflow creation should be in the form validation
Max Spring started work on JENKINS-15341 New workflow creation should be in the form validation Change By: Max Spring (24/Oct/12 11:37 PM) Status: Open In Progress 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-15617) does not work inside
Jesse Glick commented on JENKINS-15617 does not work inside …since as per http://stackoverflow.com/questions/4619668/executing-script-inside-div-retrieved-by-ajax scripts included in dynamically inserted content are not executed. You can work around this in general by using a st:adjunct of your own _javascript_, but this cannot work when st:bind has to produce part of that _javascript_ since an adjunct is static. 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-15618) Campfire Plugin crash at end of succesful build makes build fail
Yan-Fa Li created JENKINS-15618 Campfire Plugin crash at end of succesful build makes build fail Issue Type: Bug Affects Versions: current Assignee: jenslukowski Components: campfire Created: 24/Oct/12 11:18 PM Description: I'm doing multi-platform builds and on 3 of the 7 platforms I'm building this crash occurred. This is not a critical part of the build, so I would like the option for an exception to not be fatal and just simply be ignored. Notification itself to a campfire room is not an error if it fails, it's a best effort service. If you guys can figure out what this happened, that would be great, but the default behavior of making the build fail is actually not very helpful and makes me want to turn it off because it's disruptive to our builds. ERROR: Publisher hudson.plugins.campfire.CampfireNotifier aborted due to exception java.io.IOException: Stream closed at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162) at java.io.BufferedInputStream.read(BufferedInputStream.java:258) at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78) at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106) at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973) at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at hudson.plugins.campfire.Campfire.post(Campfire.java:68) at hudson.plugins.campfire.Room.speak(Room.java:29) at hudson.plugins.campfire.CampfireNotifier.publish(CampfireNotifier.java:48) at hudson.plugins.campfire.CampfireNotifier.perform(CampfireNotifier.java:80) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:782) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729) at hudson.model.Run.execute(Run.java:1541) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Environment: Centos 5 / Centos 6 / Debian Wheezy Project: Jenkins Priority: Minor Reporter: Yan-Fa Li 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-15617) does not work inside
Jesse Glick created JENKINS-15617 does not work inside Issue Type: Bug Assignee: Jesse Glick Components: core Created: 24/Oct/12 10:52 PM Description: The contents of the bind _expression_, and any further contents of your
[JIRA] (JENKINS-15616) Awful performance of ClassRealm.findResource
Jesse Glick
created JENKINS-15616
Awful performance of ClassRealm.findResource
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
core
Created:
24/Oct/12 10:17 PM
Description:
Jelly page loads are very slow due to:
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.getStackTraceElement(Native Method)
at java.lang.Throwable.getOurStackTrace(Throwable.java:826)
- locked <0x9fe56598> (a java.lang.Exception)
at java.lang.Throwable.getStackTrace(Throwable.java:815)
at org.codehaus.plexus.classworlds.realm.ClassRealm.findResource(ClassRealm.java:264)
at java.lang.ClassLoader.getResource(ClassLoader.java:1138)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadResourceFromImport(ClassRealm.java:426)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.getResource(SelfFirstStrategy.java:60)
at org.codehaus.plexus.classworlds.realm.ClassRealm.findResource(ClassRealm.java:268)
at java.lang.ClassLoader.getResource(ClassLoader.java:1138)
at java.lang.ClassLoader.getResource(ClassLoader.java:1133)
at org.jenkinsci.maven.plugins.hpi.MaskingClassLoader.getResource(MaskingClassLoader.java:37)
at org.mortbay.jetty.webapp.WebAppClassLoader.getResource(WebAppClassLoader.java:246)
- locked <0x74c0fe48> (a org.jenkinsci.maven.plugins.hpi.RunMojo$2)
at java.lang.ClassLoader.getResource(ClassLoader.java:1133)
at java.lang.ClassLoader.getResource(ClassLoader.java:1133)
at hudson.ClassicPluginStrategy$DependencyClassLoader.findResource(ClassicPluginStrategy.java:453)
at java.lang.ClassLoader.getResource(ClassLoader.java:1138)
at java.lang.ClassLoader.getResource(ClassLoader.java:1133)
at org.kohsuke.stapler.AbstractTearOff.getResource(AbstractTearOff.java:102)
…
See:
public URL findResource( String name )
{
/*
* NOTE: If this gets called from ClassLoader.getResource(String), delegate to the strategy. If this got called
* directly by other code, only scan our class path as usual for an URLClassLoader.
*/
StackTraceElement caller = new Exception().getStackTrace()[1];
if ( "java.lang.ClassLoader".equals( caller.getClassName() ) )
{
return strategy.getResource( name );
}
else
{
return super.findResource( name );
}
}
This is a very inefficient code path for such a common operation; filling in the stack trace for a Throwable is expensive.
Environment:
1.424
Project:
Jenkins
Labels:
performance
Priority:
Major
Reporter:
Jesse Glick
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-15227) changelog.xml is NOT a xml style file
eguess74 commented on JENKINS-15227 changelog.xml is NOT a xml style file It seems that this error effectively prevents the full list of users being populated, therefore I'm unable to manage some users. 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-15227) changelog.xml is NOT a xml style file
eguess74 commented on JENKINS-15227 changelog.xml is NOT a xml style file It is also spamming log file with see SAXParseException complaining about "content not allowed in prolog" and failing to parse changelog.xml for some jobs 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-15499) HistoryWidget/entry.jelly throws NullPointerException
eguess74 commented on JENKINS-15499 HistoryWidget/entry.jelly throws NullPointerException i confirm i can see that error in 1.486 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-15615) Feature Branch does not copy all modules
moacsjr created JENKINS-15615 Feature Branch does not copy all modules Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: svnmerge Created: 24/Oct/12 9:04 PM Description: My trunk project has several subversion modules. After creating a feature branch from trunk, only the first module was copied to the branch project. Due Date: 24/Oct/12 12:00 AM Environment: linux unbutu Project: Jenkins Labels: svnmerge featurebranch Priority: Minor Reporter: moacsjr 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-14764) Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle)
SCM/JIRA link daemon commented on JENKINS-14764 Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle) Code changed in jenkins User: Ross Rowe Path: pom.xml src/main/java/hudson/plugins/sauce_ondemand/BrowserAxis.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandBuildAction.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandMavenTestPublisher.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandReportFactory.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandReportPublisher.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandSurefireArchiver.java src/main/resources/hudson/plugins/sauce_ondemand/SauceOnDemandReport/summary.jelly http://jenkins-ci.org/commit/sauce-ondemand-plugin/37c4527f60414809c979117aba928a0a450c34d2 Log: JENKINS-14764 Included custom MavenTestPublisher to fix issue of embedded Sauce reports not appearing for Maven jobs. 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Bob Ballantyne edited a comment on JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception I deleted all of my Java cache, removed the "c:\Program Files\Java\jre6\lib\endorsed\xercesImpl.jar" and re-ran the test. The results are the same. I have created Issue 15613 (https://issues.jenkins-ci.org/browse/JENKINS-15613) for the CPD issue and will add the relevant info there. Thanks 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-14483) Remaining Xvfb processes in matrix jobs
zregvart resolved JENKINS-14483 as Fixed Remaining Xvfb processes in matrix jobs fixed in 1.0.4, changes in behavior are noted in the wiki (https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin) Change By: zregvart (24/Oct/12 8:43 PM) Status: Open Resolved Resolution: Fixed 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-15608) Xvfb 'specific displayname' selects a random display between 0..100, not 1..100.
zregvart resolved JENKINS-15608 as Fixed Xvfb 'specific displayname' selects a random display between 0..100, not 1..100. fixed in 1.0.4, changes in behavior are noted in the wiki (https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin) Change By: zregvart (24/Oct/12 8:43 PM) Status: Open Resolved Resolution: Fixed 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-15608) Xvfb 'specific displayname' selects a random display between 0..100, not 1..100.
zregvart commented on JENKINS-15608 Xvfb 'specific displayname' selects a random display between 0..100, not 1..100. Hi Fredrik, I've already merged pull request made by Jeroen Van Hab (https://github.com/jenkinsci/xvfb-plugin/pull/2) and made further refinement. Now the display name is based on Jenkins executor number plus a configurable offset (1 by default). This provides uniqueness - no two executors have the same number, and one executor executes only one job at a time. The offset that is configurable can be used to separate Jenkins run Xvfbs from other Xvfb or X servers run on the same machine. I will release these changes in a few minutes as 1.0.4. 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-15562) Support setting the client version
kutzi commented on JENKINS-15562 Support setting the client version I see that there is a use case, but I don't see that this use case is critical to have. We could have all kind of data - even dynamic information - included in the 'default' version. There are - for my taste - even too many option in the Advanced section, already. So again my question: would a default version be enough? 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-3425) Work around javaws incorrectly putting quotes into the PATH environment variable
Alex Okrushko assigned JENKINS-3425 to Kohsuke Kawaguchi Work around javaws incorrectly putting quotes into the PATH environment variable Change By: Alex Okrushko (24/Oct/12 4:12 PM) Assignee: Kohsuke Kawaguchi 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-12575) Add option to sort JUNIT tests by date (currently ordered alphabetically)
Alex Okrushko updated JENKINS-12575 Add option to sort JUNIT tests by date (currently ordered alphabetically) Change By: Alex Okrushko (24/Oct/12 4:07 PM) Priority: Minor Major 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-15475) CreateProcess error=87, The parameter is incorrect
Alex Okrushko commented on JENKINS-15475 CreateProcess error=87, The parameter is incorrect I have the same problem, however this happens only on master and only when I use in combination with Node and Label parameter plugin (e.g. set the node as "master"): Started by upstream project "run_everywhere" build number 21 originally caused by: Started by user alexo [EnvInject] - Loading node environment variables. Building on master in workspace C:\Users\alexo\jenkins\jobs\run_cmd\workspace\default Updating https://server.com/trunk/ to revision '2012-10-24T11:59:51.563 -0400' At revision 60 [default] $ cmd /c call C:\Windows\TEMP\hudson8635809542653204475.bat The parameter is incorrect FATAL: command execution failed java.io.IOException: Cannot run program "cmd" (in directory "C:\Users\alexo\jenkins\jobs\run_cmd\workspace\default"): CreateProcess error=87, The parameter is incorrect at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.(Proc.java:244) at hudson.Proc$LocalProc.(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:716) at hudson.Launcher$ProcStarter.start(Launcher.java:345) at hudson.Launcher$ProcStarter.join(Launcher.java:352) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1502) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException: CreateProcess error=87, The parameter is incorrect at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source) ... 17 more Build step 'Execute Windows batch command' marked build as failure Finished: FAILURE 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-11868) Add configuration slicer for Jenkins build timeout plugin
Jakub M. commented on JENKINS-11868 Add configuration slicer for Jenkins build timeout plugin Is this feature is in 1.33 version? I can't find it in "Configuration Slicing". 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-11280) Downstream project name is not accepting env variable/build parameters
Ondrej Kupka commented on JENKINS-11280 Downstream project name is not accepting env variable/build parameters Same here. Just had an idea how to make our Jenkins working in a much better way, and in fact fix some issues, and what I see is that it does not work. What a pity :-/ 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-15613) DryPublisher aborts due to exception
Bob Ballantyne updated JENKINS-15613 DryPublisher aborts due to exception Change By: Bob Ballantyne (24/Oct/12 3:29 PM) Attachment: System_Info.pdf Attachment: cpd.xml Affects Version/s: current Description: I am running Jenkins 1.486 on an OpenSUSE linux with various plugins (see attached System_Info.pdf for full list). I have 2 Windows slaves attached on which I run FLEX build/analysis/unit-test/flexcover. (This is a follow on from https://issues.jenkins-ci.org/browse/JENKINS-15593 - and has the workaround which includes "c:\Program Files\Java\jre6\lib\endorsed\xercesImpl.jar" to prevent exceptions).I have one slave with:java version "1.6.0_26"Java(TM) SE Runtime Environment (build 1.6.0_26-b03)Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)the other uses:java version "1.6.0_35"Java(TM) SE Runtime Environment (build 1.6.0_35-b10)Java HotSpot(TM) Client VM (build 20.10-b01, mixed mode, sharing)The issue occurs on both.I connect both slaves to the master using slave-agent.jnlpFor static analysis, I use FlexPMD which produces pmd.xml and cpd.xml files. Whenever I try to publish a cpd.xml file (from either slave), I get the following exception:[DRY] Collecting duplicate code analysis files...ERROR: Publisher hudson.plugins.dry.DryPublisher aborted due to exceptionjava.lang.NullPointerException at org.apache.commons.digester3.Digester.getXMLReader(Digester.java:799) at org.apache.commons.digester3.Digester.parse(Digester.java:1642) at org.apache.commons.digester3.Digester.parse(Digester.java:1701) at hudson.plugins.dry.parser.cpd.CpdParser.accepts(CpdParser.java:48) at hudson.plugins.dry.parser.DuplicationParserRegistry.parse(DuplicationParserRegistry.java:77) at hudson.plugins.analysis.core.FilesParser.parseFile(FilesParser.java:261) at hudson.plugins.analysis.core.FilesParser.parseFiles(FilesParser.java:220) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:169) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:31) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2308) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source)Finished: FAILUREThe Java console on the slave shows the following:Oct 24, 2012 11:23:38 AM com.youdevise.hudson.slavestatus.SlaveListener callINFO: Slave-status listener startingOct 24, 2012 11:23:38 AM com.youdevise.hudson.slavestatus.SocketHTTPListener waitForConnectionINFO: Slave-status listener ready on port 3141Oct 24, 2012 11:23:55 AM org.apache.commons.digester3.Digester getParserSEVERE: Digester.getParser: java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null" at javax.xml.parsers.SAXParserFactory.setXIncludeAware(Unknown Source) at org.apache.commons.digester3.Digester.getFactory(Digester.java:439) at org.apache.commons.digester3.Digester.getParser(Digester.java:652) at org.apache.commons.digester3.Digester.getXMLReader(Digester.java:799) at org.apache.commons.digester3.Digester.parse(Digester.java:1642) at org.apache.commons.digester3.Digester.parse(Digester.java:1701) at hudson.plugins.dry.parser.cpd.CpdParser.accepts(CpdParser.java:48) at hudson.plugins.dry.parser.DuplicationParserRegistry.parse(DuplicationParserRegistry.java:77) at hudson.plugins.analysis.core.FilesParser.parseFile(FilesParser.java:261) at hudson.plugins.analysis.core.FilesParser.parseFiles(FilesP
[JIRA] (JENKINS-15610) Jenkins seems confused about version
Ben McDonie resolved JENKINS-15610 as Not A Defect Jenkins seems confused about version This must have been a side-effect of leftover or cached artifacts in my glassfish domain. I deleted everything related to Jenkins and redeployed. Seems OK now. Change By: Ben McDonie (24/Oct/12 3:23 PM) Status: Open Resolved Resolution: Not A Defect 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-15614) Create default list of users and groups
Jesse Glick created JENKINS-15614 Create default list of users and groups Issue Type: Improvement Assignee: Jesse Glick Components: mock-security-realm Created: 24/Oct/12 3:20 PM Description: Rather than forcing the tester to come up with some fake user names and groups, pull the sample (or something similar) out of the inline help and just make it the default value. Project: Jenkins Priority: Major Reporter: Jesse Glick 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Bob Ballantyne commented on JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception I deleted all of my Java cache, removed the "c:\Program Files\Java\jre6\lib\endorsed\xercesImpl.jar" and re-ran the test. The results are the same. I have created Issue 15612 for the CPD issue and will add the relevant info there. Thanks 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-15613) DryPublisher aborts due to exception
Bob Ballantyne created JENKINS-15613 DryPublisher aborts due to exception Issue Type: Bug Assignee: Unassigned Components: plugin Created: 24/Oct/12 3:13 PM Due Date: 24/Oct/12 12:00 AM Project: Jenkins Priority: Major Reporter: Bob Ballantyne 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-13009) Updates create a lot of Jira user sessions
Elizabeth Schaefermann commented on JENKINS-13009 Updates create a lot of Jira user sessions We cannot use Jenkins in conjunction with JIRA until this issue is resolved. 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-12983) Redundat syncs when using matrix jobs
Rob Petti assigned JENKINS-12983 to Kohsuke Kawaguchi Redundat syncs when using matrix jobs Change By: Rob Petti (24/Oct/12 3:11 PM) Assignee: Kohsuke Kawaguchi 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-12983) Redundat syncs when using matrix jobs
Thomas Fields commented on JENKINS-12983 Redundat syncs when using matrix jobs So 7 months further down the line and still no word on this 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-15601) Main dashboard takes minutes to load in browser
kutzi commented on JENKINS-15601 Main dashboard takes minutes to load in browser A stack dump of the Jenkins process while in the process of loading the page could help to diagnose the problem. kill -3 or jstack 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-2787) Hudson doesn't support Maven2 dependency version ranges
kutzi commented on JENKINS-2787 Hudson doesn't support Maven2 dependency version ranges AFAIK, dependency ranges support was added to Jenkins in the last weeks, but I also remember that this triggered some bugs (but more for too eager matching). Sorry, wasn't following this closely. If you're having problems with dependency resolution you should ask on the users list which is a much better forum to get help than an issue tracker. 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-15612) Configuration Slicer for Jenkins Build Timeout Plugin missing in Version 1.33?
Stephan Weber created JENKINS-15612 Configuration Slicer for Jenkins Build Timeout Plugin missing in Version 1.33? Issue Type: Bug Assignee: mdonohue Components: configurationslicing Created: 24/Oct/12 2:02 PM Description: I can't find Configuration Slicer for Jenkins Build Timeout Plugin in Version 1.33. Did you remove it sometimes after Version 1.27? => It solved JENKINS-11868 - Add configuration slicer for Jenkins build timeout plugin Regards, Stephan Project: Jenkins Priority: Major Reporter: Stephan Weber 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-15611) Builds launched programmatically via Queue.schedule() fail with error
Jeff Maxwell updated JENKINS-15611 Builds launched programmatically via Queue.schedule() fail with error Change By: Jeff Maxwell (24/Oct/12 1:47 PM) Description: Builds launched programmatically via Queue.schedule() fail with error2012-10-23 22:39:15 | Started2012-10-23 22:39:15 | [EnvInject] - Loading node environment variables.2012-10-23 22:39:15 | [EnvInject] - [ERROR] - SEVERE ERROR occurs: null2012-10-23 22:39:15 | Finished: FAILURE This happens any job regardless if EnvInject is turned on 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-15611) Builds launched programmatically via Queue.schedule() fail with error
Jeff Maxwell updated JENKINS-15611 Builds launched programmatically via Queue.schedule() fail with error Change By: Jeff Maxwell (24/Oct/12 1:47 PM) Description: Builds launched programmatically via Queue.schedule() fail with error2012-10-23 22:39:15 | Started2012-10-23 22:39:15 | [EnvInject] - Loading node environment variables.2012-10-23 22:39:15 | [EnvInject] - [ERROR] - SEVERE ERROR occurs: null2012-10-23 22:39:15 | Finished: FAILUREThis happens any on every job regardless if EnvInject is turned on 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-15611) Builds launched programmatically via Queue.schedule() fail with error
Jeff Maxwell created JENKINS-15611 Builds launched programmatically via Queue.schedule() fail with error Issue Type: Bug Assignee: Gregory Boissinot Components: envinject Created: 24/Oct/12 1:43 PM Description: Builds launched programmatically via Queue.schedule() fail with error 2012-10-23 22:39:15 | Started 2012-10-23 22:39:15 | [EnvInject] - Loading node environment variables. 2012-10-23 22:39:15 | [EnvInject] - [ERROR] - SEVERE ERROR occurs: null 2012-10-23 22:39:15 | Finished: FAILURE Environment: Jenkins 1.486 Plugin 1.72 Solaris Project: Jenkins Priority: Blocker Reporter: Jeff Maxwell 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-15609) New created EC2 instance SCP Error
vinz r
updated JENKINS-15609
New created EC2 instance SCP Error
Change By:
vinz r
(24/Oct/12 1:22 PM)
Description:
When starting the new EC2 instance as slave node encountered a problem:
{noformat}
java full version "1.6.0_24-b24"Copying slave.jarERROR: Error during SCP transfer.java.io.IOException: Error during SCP transfer. at com.trilead.ssh2.SCPClient.put(SCPClient.java:523) at com.trilead.ssh2.SCPClient.put(SCPClient.java:476) at hudson.plugins.ec2.ssh.EC2UnixLauncher.launch(EC2UnixLauncher.java:126) at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:57) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636)Caused by: java.io.IOException: Remote scp terminated unexpectedly. at com.trilead.ssh2.SCPClient.readResponse(SCPClient.java:50) at com.trilead.ssh2.SCPClient.sendBytes(SCPClient.java:140) at com.trilead.ssh2.SCPClient.put(SCPClient.java:519) ... 9 more
{noformat}
On Master Jenkins the Error logs says"{noformat}ct 24, 2012 6:06:43 AM hudson.slaves.NodeProvisioner updateWARNING: Provisioned slave Jenkins Slaves (ami-4afe4623) failed to launchjava.util.concurrent.ExecutionException: java.io.IOException: Slave failed to connect, even though the launcher didn't report it. See the log output for details. at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at hudson.plugins.ec2.EC2Cloud$1.call(EC2Cloud.java:253) at hudson.plugins.ec2.EC2Cloud$1.call(EC2Cloud.java:239) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636)Caused by: java.io.IOException: Slave failed to connect, even though the launcher didn't report it. See the log output for details. at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:221) ... 5 more{noformat}
But re-lunching the slave nodes it runs properly. Is this a bug for EC2 plugin?Current Jenkins version 1.487 and Amazon EC2 Plugins is 1.17 Thanks,Vinz
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-15610) Jenkins seems confused about version
Ben McDonie created JENKINS-15610 Jenkins seems confused about version Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: about_jenkins.png, version_bottom.png Components: versionnumber Created: 24/Oct/12 1:15 PM Description: I upgraded Jenkins to 1.487 this morning. I undeployed the old Jenkins application (1.486) from my Glassfish server. I deployed the new Jenkins WAR (1.487) to my Glassfish server. In most places, the version reads "1.486" (see attached). On the "About Jenkins" page, I get conflicting version numbers (see attached). Any help is appreciated! Environment: Windows 7 x64 Deployed on Glassfish Open Source (3.1.2.2) Project: Jenkins Labels: jenkins upgrade version Priority: Major Reporter: Ben McDonie 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-15609) New created EC2 instance SCP Error
vinz r created JENKINS-15609 New created EC2 instance SCP Error Issue Type: Bug Affects Versions: current Assignee: Francis Upton Components: ec2, scp Created: 24/Oct/12 1:14 PM Description: When starting the new EC2 instance as slave node encountered a problem: java full version "1.6.0_24-b24" Copying slave.jar ERROR: Error during SCP transfer. java.io.IOException: Error during SCP transfer. at com.trilead.ssh2.SCPClient.put(SCPClient.java:523) at com.trilead.ssh2.SCPClient.put(SCPClient.java:476) at hudson.plugins.ec2.ssh.EC2UnixLauncher.launch(EC2UnixLauncher.java:126) at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:57) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.io.IOException: Remote scp terminated unexpectedly. at com.trilead.ssh2.SCPClient.readResponse(SCPClient.java:50) at com.trilead.ssh2.SCPClient.sendBytes(SCPClient.java:140) at com.trilead.ssh2.SCPClient.put(SCPClient.java:519) ... 9 more But re-lunching the slave nodes it runs properly. Is this a bug for EC2 plugin? Current Jenkins version 1.487 and Amazon EC2 Plugins is 1.17 Thanks, Vinz Fix Versions: current Project: Jenkins Priority: Critical Reporter: vinz r 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-15601) Main dashboard takes minutes to load in browser
David Resnick edited a comment on JENKINS-15601 Main dashboard takes minutes to load in browser I spoke too soon. The problem still occurs (though possibly less frequently) with 1.487. Exception like this are found in the log around the same time the pages take a long time to load. Oct 24, 2012 9:12:59 AM org.kohsuke.stapler.compression.CompressionFilter reportException WARNING: Untrapped servlet exception winstone.ClientSocketException: Failed to write to client at winstone.ClientOutputStream.write(ClientOutputStream.java:41) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119) at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112) at java.util.zip.GZIPOutputStream.finish(Unknown Source) at java.util.zip.DeflaterOutputStream.close(Unknown Source) at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36) at net.bull.javamelody.FilterServletOutputStream.close(FilterServletOutputStream.java:46) at java.io.FilterOutputStream.close(Unknown Source) at sun.nio.cs.StreamEncoder.implClose(Unknown Source) at sun.nio.cs.StreamEncoder.close(Unknown Source) at java.io.OutputStreamWriter.close(Unknown Source) at java.io.BufferedWriter.close(Unknown Source) at org.dom4j.io.XMLWriter.close(XMLWriter.java:286) at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.C
[JIRA] (JENKINS-15601) Main dashboard takes minutes to load in browser
David Resnick
edited a comment on JENKINS-15601
Main dashboard takes minutes to load in browser
I spoke too soon. The problem still occurs (though possibly less frequently) with 1.487. Exception like this are found in the log around the same time the pages take a long time to load.
{{
Oct 24, 2012 9:12:59 AM org.kohsuke.stapler.compression.CompressionFilter reportException
WARNING: Untrapped servlet exception
winstone.ClientSocketException: Failed to write to client
at winstone.ClientOutputStream.write(ClientOutputStream.java:41)
at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181)
at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119)
at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112)
at java.util.zip.GZIPOutputStream.finish(Unknown Source)
at java.util.zip.DeflaterOutputStream.close(Unknown Source)
at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36)
at net.bull.javamelody.FilterServletOutputStream.close(FilterServletOutputStream.java:46)
at java.io.FilterOutputStream.close(Unknown Source)
at sun.nio.cs.StreamEncoder.implClose(Unknown Source)
at sun.nio.cs.StreamEncoder.close(Unknown Source)
at java.io.OutputStreamWriter.close(Unknown Source)
at java.io.BufferedWriter.close(Unknown Source)
at org.dom4j.io.XMLWriter.close(XMLWriter.java:286)
at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70)
at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56)
at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107)
at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at hudson.securit
[JIRA] (JENKINS-15601) Main dashboard takes minutes to load in browser
David Resnick commented on JENKINS-15601 Main dashboard takes minutes to load in browser I spoke too soon. The problem still occurs (though possibly less frequently) with 1.487. Exception like this are found in the log around the same time the pages take a long time to load. Oct 24, 2012 9:12:59 AM org.kohsuke.stapler.compression.CompressionFilter reportException WARNING: Untrapped servlet exception winstone.ClientSocketException: Failed to write to client at winstone.ClientOutputStream.write(ClientOutputStream.java:41) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119) at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112) at java.util.zip.GZIPOutputStream.finish(Unknown Source) at java.util.zip.DeflaterOutputStream.close(Unknown Source) at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36) at net.bull.javamelody.FilterServletOutputStream.close(FilterServletOutputStream.java:46) at java.io.FilterOutputStream.close(Unknown Source) at sun.nio.cs.StreamEncoder.implClose(Unknown Source) at sun.nio.cs.StreamEncoder.close(Unknown Source) at java.io.OutputStreamWriter.close(Unknown Source) at java.io.BufferedWriter.close(Unknown Source) at org.dom4j.io.XMLWriter.close(XMLWriter.java:286) at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.Chaine
[JIRA] (JENKINS-15608) Xvfb 'specific displayname' selects a random display between 0..100, not 1..100.
Fredrik Vihlborg created JENKINS-15608 Xvfb 'specific displayname' selects a random display between 0..100, not 1..100. Issue Type: Bug Affects Versions: current Assignee: zregvart Components: xvfb Created: 24/Oct/12 1:04 PM Description: The setting "Xvfb specific displayname" should select a random display from 1..100 if not specified. However, it can also select display 0, which could make the job fail if X is already running on :0. From log output: Xvfb starting$ Xvfb :0 -screen 0 1024x768x24 -fbdir /var/lib/jenkins/2012-10-24_14-31-395902912578711360537xvfb Project: Jenkins Priority: Major Reporter: Fredrik Vihlborg 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-15607) SCM Sync configuration plugin installation failed due to inability to delete antlr-2.7.6.jar
Matthew Jones created JENKINS-15607 SCM Sync configuration plugin installation failed due to inability to delete antlr-2.7.6.jar Issue Type: Bug Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 24/Oct/12 12:35 PM Description: I was trying to add the SCM Sync configuration to my Jenkins installation. It fails with the following trace. The odd thing is that the file in question has only just been created (as part of the installation). It is repeatable: I stopped the service, deleted the entire plugin dir and restarted, retried: same fault. 24-Oct-2012 11:35:03 hudson.model.UpdateCenter$DownloadJob run SEVERE: Failed to install SCM Sync configuration plugin hudson.util.IOException2: Failed to dynamically deploy this plugin at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1227) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1037) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Unable to delete C:\Jenkins\plugins\scm-sync-configuration\WEB-INF\lib\antlr-2.7.6.jar at hudson.Util.deleteFile(Util.java:243) at hudson.Util.deleteRecursive(Util.java:293) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.ClassicPluginStrategy.explode(ClassicPluginStrategy.java:403) at hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.java:117) at hudson.PluginManager.dynamicLoad(PluginManager.java:388) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1223) ... 7 more 24-Oct-2012 11:35:02 hudson.PluginManager dynamicLoad INFO: Attempting to dynamic load C:\Jenkins\plugins\scm-sync-configuration.jpi 24-Oct-2012 11:35:02 hudson.model.UpdateCenter$UpdateCenterConfiguration download INFO: Downloading SCM Sync configuration plugin 24-Oct-2012 11:35:01 hudson.model.UpdateCenter$DownloadJob run INFO: Starting the installation of SCM Sync configuration plugin on behalf of anonymous 24-Oct-2012 11:34:48 hudson.WebAppMain$2 run INFO: Jenkins is fully up and running Environment: Jenkins 1.484 running on Windows. Plugin v0.0.6 installed via standard Jenkins plugin manager Project: Jenkins Priority: Major Reporter: Matthew Jones 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-15606) CloverPHP : error during configuration of cloverPHP in job
Jurgen Van Bouchaute created JENKINS-15606 CloverPHP : error during configuration of cloverPHP in job Issue Type: Bug Affects Versions: current Assignee: sogabe Attachments: 24-10-2012 14-26-46.png Components: cloverphp-plugin Created: 24/Oct/12 12:29 PM Description: If I add a post-build step "publish Clover PHP Coverage report" to a job, I get a 404 resource not found twice on the configuration panel Environment: Jenkins version 1.464 Windows Project: Jenkins Labels: plugin exception Priority: Major Reporter: Jurgen Van Bouchaute 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-15011) Jacoco Plugin 1.0.3 - no threshold config and displays broken graphic link
H Mlnarik commented on JENKINS-15011 Jacoco Plugin 1.0.3 - no threshold config and displays broken graphic link The issue is also present in version 1.0.8 of JaCoCo plugin. 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-15045) Support Github commit status API
David Henderson commented on JENKINS-15045 Support Github commit status API @Nicolas - that looks good - I'm not sure it would belong in ghprb-plugin though. My use case: Push a commit The github plugin triggers a build The github plugin reports status of build for the SHA that it built I then create a pull request. In theory, the pull request will show the status of the build (once it is complete) Merge the PR if the status is success or make changes if it fails While this would fit with the pull request builder, I don't think it should be required that you use that to create the pull requests if you want the build statuses pushed to github. 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Ulli Hafner commented on JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception Ok, thanks for the detailed input. Just to be sure: can you please clean up your JLNP classes cache so that all classes are reloaded from the master. Somehow the correct XML parser is not found on your machine in the PMD issue. Maybe another tool defined that SAX parser instance and now my plug-in tries to reuse it (which is not on the class path). I need to investigate how I can reset the XML parser. The second problem is different. Can you please attach the cpd.xml file? (Or clone this issue since these two problems seem to be unrelated) 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-2787) Hudson doesn't support Maven2 dependency version ranges
b p commented on JENKINS-2787 Hudson doesn't support Maven2 dependency version ranges "Meanwhile, in a secret room a lot closer than you might think." Hello kutzi, I see your comment "you CAN use Jenkins with dependency ranges. It's just that automatic linking of jobs via SNAPSHOT dependencies doesn't work. Everything else should work fine" If I understand correctly, our current project (containing some range dependencies) should be able to be build on jenkins ? Cause it's not I get ... . Failed to collect dependencies for [com.myjar:myjar:jar:[4.0.0,) (compile) (on my machine all is well) Am I missing something ? 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-8535) Build should not be marked as failed when tests do not pass
Alex Anderson commented on JENKINS-8535 Build should not be marked as failed when tests do not pass Have fixed this and submitted a pull request on Github: https://github.com/jenkinsci/grails-plugin/pull/3 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-13160) Manually triggering a build, which clones a workspace, which is then used by the Multiple SCM Plugin causes job failure
Zaraki Kenpachi commented on JENKINS-13160 Manually triggering a build, which clones a workspace, which is then used by the Multiple SCM Plugin causes job failure can someone please fix this problem? ken graham has even posted a solution. 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-9410) Remote API for creating a new Job is not working - using createItem
Kannan Manickam commented on JENKINS-9410 Remote API for creating a new Job is not working - using createItem I had the same issue. As Kevin Sawicki said, I set the content_type which resolved this issue for me. 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-15601) Main dashboard takes minutes to load in browser
David Resnick commented on JENKINS-15601 Main dashboard takes minutes to load in browser I was severely impacted by this problem when using Jenkins 1.486 (on a 32 bit Windows Server Enterprise). The problem seems like it may be fixed in 1.487 – I haven't encountered it in the first couple of hours since installation. 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
