[JIRA] (JENKINS-16237) Extended email plugin no longer sends messages on latest
Jamie Penman-Smithson commented on JENKINS-16237 Extended email plugin no longer sends messages on latest To test this I ran the exact same Jenkins installation under Winstone - it works perfectly, so I definitely think this is related to Tomcat. 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-16263) Return the number of the build that was triggered using REST API.
Jakub Senko created JENKINS-16263 Return the number of the build that was triggered using REST API. Issue Type: Improvement Assignee: Unassigned Components: www Created: 05/Jan/13 5:27 PM Description: When using the REST API to programatically trigger a build, there is no way to atomically retrieve the number of the build which has been triggered (except by using plugins or workarounds). This would enable REST clients to work with the triggered build, for example waiting for the build to finish and retrieve the results, when there is a possibility that multiple clients can trigger the build at the same time. Current status: POST request to the https://.../job/job name/build url will trigger a build and return a html page of the job overview. Proposed solution: Add a parameter to the request that will return a text response with the number of the triggered build instead of a html page. Project: Jenkins Priority: Minor Reporter: Jakub Senko 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-16263) Return the number of the build that was triggered using REST API.
Jakub Senko updated JENKINS-16263 Return the number of the build that was triggered using REST API. Change By: Jakub Senko (05/Jan/13 5:33 PM) Description: WhenusingtheRESTAPItoprogramaticallytriggerabuild,thereisnowaytoatomicallyretrievethenumberofthebuildwhichhasbeentriggered(exceptbyusingpluginsorworkarounds).ThiswouldenableRESTclientstoworkwiththetriggeredbuild,forexamplewaitingforthebuildtofinishandretrievetheresults,whenthereisapossibilitythatmultipleclientscantrigger the a buildatthesametime.Currentstatus:POSTrequesttothehttps://[...]/job/[jobname]/buildurlwilltriggerabuildandreturnahtmlpageofthejoboverview.Proposedsolution:Addaparametertotherequestthatwillreturnatextresponsewiththenumberofthetriggeredbuildinsteadofahtmlpage. 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-1) Ability to push the build results to another Hudson
SCM/JIRA link daemon commented on JENKINS-1 Ability to push the build results to another Hudson Code changed in jenkins User: Christopher Orr Path: src/main/java/org/jenkinsci/backend/ircbot/IrcBotImpl.java http://jenkins-ci.org/commit/backend-ircbot/240c967943fbf3b23d8215a8ebee2b066d89c9ef Log: Don't match on single-digit issue numbers. This is a quick fix for people asking about "jenkins-1.456.deb" which the IRC bot would always interpret as JIRA issue "JENKINS-1". Compare: https://github.com/jenkinsci/backend-ircbot/compare/78ea690f32e7...240c967943fb 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-15119) Duration sorting is incorrect in TestNG report
SCM/JIRA link daemon commented on JENKINS-15119 Duration sorting is incorrect in TestNG report Code changed in jenkins User: Nalin Makar Path: README src/main/java/hudson/plugins/testng/util/FormatUtil.java src/test/java/hudson/plugins/testng/util/FormatUtilTest.java http://jenkins-ci.org/commit/testng-plugin-plugin/b71d891567cb85434b6d56d85915e7b0a8cbbf10 Log: Fixed: JENKINS-15119 - Duration sorting is incorrect in TestNG report 1. Sorting in Jenkins table is alphabetic and that was a problem for how we were formatting duration string. Also, our duration strings were difficult to read. Changed it to be: a. " 24hrs", or b. hh:mm:ss.ZZZ This takes care of sorting as well as makes reading/comparing the time duration easier across multiple rows. Added FormatUtilTest as well. Compare: https://github.com/jenkinsci/testng-plugin-plugin/compare/d39f3bb74efe...b71d891567cb 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-15119) Duration sorting is incorrect in TestNG report
nalin_makar resolved JENKINS-15119 as Fixed Duration sorting is incorrect in TestNG report Change By: nalin_makar (05/Jan/13 6:32 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space
Johno Crawford commented on JENKINS-13617 64-bit java.lang.OutOfMemoryError: PermGen space Niklaus, if there are no memory dumps in that time I think we can rule PeriodicBackup plugin as the culprit and there is no need to move Jenkins to run under Tomcat. I have merged the fixes to the PeriodicBackup plugin repo (1.2+ contains the fixes in my snapshot) which should now be available from your plugin manager (you may need to click "Check now" in the advanced tab). The exception java.lang.OutOfMemoryError: PermGen space is generic, depends on how Jenkins is used, what plugins you have installed etc. there is no way to avoid it if there is a class loader memory leak, increasing the max permsize, enabling other switches which modify the JVM GC behaviour will (most of the time) prolong the ticking time bomb. For those interested in knowing more about PermGen check out this article: http://frankkieviet.blogspot.ca/2006/10/classloader-leaks-dreaded-permgen-space.html If there are others receiving this error after increasing both -XX:MaxPermSize and -Xmx to reasonable values it might be caused by plugin(s) you have installed or the way you use Jenkins, however without a heap dump to analyse it is practically impossible to debug. 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-13563) Attachment filepath does not support token reference
Pavel Kudrys commented on JENKINS-13563 Attachment filepath does not support token reference Hi, I'm new to Jenkins and I just hit on the same problem, as if some tokens are still not supported in the attachment field? Or maybe I'm using it in a wrong way? I'm using this path in the attachment field... Reports/Report_$BUILD_NUMBER.rxzlog where the $BUILD_NUMBER is supposed to translate to the build number. This variable works OK in other fields, but not in the attachment field. The file is correctly attached only if I replace the $BUILD_NUMBER variable with the number. But as you can imagine, it's not ideal solution as the number of the .rxzlog file changes with every build. I'm using Jenkins ver. 1.496. Thanks in advance! 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space
Johno Crawford edited a comment on JENKINS-13617 64-bit java.lang.OutOfMemoryError: PermGen space Niklaus, if there are no memory dumps in that time I think we can rule PeriodicBackup plugin as the culprit and there is no need to move Jenkins to run under Tomcat. I have merged the fixes to the PeriodicBackup plugin repo (1.2+ contains the fixes in my snapshot) which should now be available from your plugin manager (you may need to click "Check now" in the advanced tab). The exception java.lang.OutOfMemoryError: PermGen space is generic, depends on how Jenkins is used, what plugins you have installed etc. there is no way to avoid it if there is a class loader memory leak, increasing the max permsize, enabling other switches which modify the JVM GC behaviour will (most of the time) prolong the ticking time bomb. For those interested in knowing more about PermGen check out this article: http://frankkieviet.blogspot.ca/2006/10/classloader-leaks-dreaded-permgen-space.html If there are others receiving this error after increasing both -XX:MaxPermSize and -Xmx to reasonable values it might be caused by plugin(s) you have installed or the way you use Jenkins (there might be undiscovered memory leaks in core), however without a heap dump to analyse it is practically impossible to debug due to the size of the code base and large amount of plugins. 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space
Johno Crawford edited a comment on JENKINS-13617 64-bit java.lang.OutOfMemoryError: PermGen space Niklaus, if there are no memory dumps in that time I think we can rule PeriodicBackup plugin as the culprit and there is no need to move Jenkins to run under Tomcat. I have merged the fixes to the PeriodicBackup plugin repo JENKINS-16223 (1.2+ contains the fixes in my snapshot) which should now be available from your plugin manager (you may need to click "Check now" in the advanced tab). The exception java.lang.OutOfMemoryError: PermGen space is generic, depends on how Jenkins is configured, used, what plugins you have installed etc. there is no way to avoid it if there is a class loader memory leak, increasing the max permsize, enabling other switches which modify the JVM GC behaviour will (most of the time) prolong the ticking time bomb. For those interested in knowing more about PermGen check out this article: http://frankkieviet.blogspot.ca/2006/10/classloader-leaks-dreaded-permgen-space.html If there are others receiving this error after increasing both -XX:MaxPermSize and -Xmx to reasonable values the OOM might be caused by plugin(s) you have installed or the way you use Jenkins (there might be undiscovered memory leaks in core), however without a heap dump to analyse it is practically impossible to debug due to the size of the code base and amount of plugins. Adam, instead of using the switch -XX:PermSize you should be using -XX:MaxPermSize, in addition, 64bit JVM will use almost double the amount of memory for object pointers ( https://wikis.oracle.com/display/HotSpotInternals/CompressedOops ). You can try adding -XX:+UseCompressedOops to your JVM args to help, however you may have ran into a memory leak like Niklaus (in which case a heap dump is required). 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space
Johno Crawford edited a comment on JENKINS-13617 64-bit java.lang.OutOfMemoryError: PermGen space Niklaus, if there are no memory dumps in that time I think we can rule PeriodicBackup plugin as the culprit and there is no need to move Jenkins to run under Tomcat. I have merged the fixes to the PeriodicBackup plugin repo JENKINS-16223 (1.2+ contains the fixes in my snapshot) which should now be available from your plugin manager (you may need to click "Check now" in the advanced tab). The exception java.lang.OutOfMemoryError: PermGen space is generic, there is no way to avoid it if there is a class loader memory leak, increasing the max permsize, enabling other switches which modify the JVM GC behaviour will (most of the time) prolong the ticking time bomb. For those interested in knowing more about PermGen check out this article: http://frankkieviet.blogspot.ca/2006/10/classloader-leaks-dreaded-permgen-space.html If there are others receiving this error after increasing both -XX:MaxPermSize and -Xmx to reasonable values the OOM might be caused by plugin(s) you have installed or the way you use Jenkins (there might be undiscovered memory leaks in core), however without a heap dump to analyse it is practically impossible to debug due to the size of the code base and amount of plugins. Adam, instead of using the switch -XX:PermSize you should be using -XX:MaxPermSize, in addition, 64bit JVM will use almost double the amount of memory for object pointers ( https://wikis.oracle.com/display/HotSpotInternals/CompressedOops ). You can try adding -XX:+UseCompressedOops to your JVM args to help, however you may have ran into a memory leak like Niklaus (in which case a heap dump is required). 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-13188) Recognize test results from com.github.searls:jasmine-maven-plugin
kutzi resolved JENKINS-13188 as Duplicate Recognize test results from com.github.searls:jasmine-maven-plugin Change By: kutzi (05/Jan/13 10:27 PM) Status: Open Resolved Resolution: Duplicate 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-12046) TestNG shouldn't look for result files if build was aborted
SCM/JIRA link daemon commented on JENKINS-12046 TestNG shouldnt look for result files if build was aborted Code changed in jenkins User: Nalin Makar Path: README pom.xml src/main/java/hudson/plugins/testng/Publisher.java src/test/java/hudson/plugins/testng/PublisherTest.java http://jenkins-ci.org/commit/testng-plugin-plugin/fa2df404a99ef2fd27ca48ef2fb3bac5337f539c Log: Fixed: JENKINS-12046 - TestNG shouldn't look for result files if build was aborted (again!) Also added a test for 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-13726) Github plugin should work with Guthub enterprise by allowing for overriding the github URL
Johno Crawford commented on JENKINS-13726 Github plugin should work with Guthub enterprise by allowing for overriding the github URL Before working on the actual Jenkins plugin source it requires changes to the api dependency to support custom github servers. I have created a PR at https://github.com/kohsuke/github-api/pull/24/files . 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-12046) TestNG shouldn't look for result files if build was aborted
nalin_makar resolved JENKINS-12046 as Fixed TestNG shouldnt look for result files if build was aborted Change By: nalin_makar (05/Jan/13 11:57 PM) Status: Reopened 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-13563) Attachment filepath does not support token reference
Slide-O-Mix commented on JENKINS-13563 Attachment filepath does not support token reference I removed this as normally you would just use an ANT file pattern to match the files. Are your rxzlog files maintained between builds? Meaning, are there multiple rxzlog files in the workspace? 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-16237) Extended email plugin no longer sends messages on latest
Slide-O-Mix commented on JENKINS-16237 Extended email plugin no longer sends messages on latest I'm still not able to replicate this even under Tomcat. The emails get sent just fine for me. Can you send me the test config you used? 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-13726) Github plugin should work with Guthub enterprise by allowing for overriding the github URL
Johno Crawford assigned JENKINS-13726 to Johno Crawford Github plugin should work with Guthub enterprise by allowing for overriding the github URL Change By: Johno Crawford (06/Jan/13 4:01 AM) Assignee: JohnoCrawford 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-16163) NullPointerException when sending post build emails - all triggers appear to be impacted
Slide-O-Mix commented on JENKINS-16163 NullPointerException when sending post build emails - all triggers appear to be impacted Do you have the "Mailer" plugin disabled in your config? 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-13563) Attachment filepath does not support token reference
Pavel Kudrys commented on JENKINS-13563 Attachment filepath does not support token reference Hi, Thank you for the reply! So the BUILD_NUMBER token is not allowed in the way I used it? Could you please suggest me the correct ANT pattern using the BUILD_NUMBER token? Yes, there are multiple rxzlog in the workspace (new rxzlog is created with every new build). At the moment, I prefer to keep them all in the Reports folder. Therefore, I can't use path with *.rxzlog or similar wildcards. Have a nice day, Pavel 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-13563) Attachment filepath does not support token reference
Pavel Kudrys edited a comment on JENKINS-13563 Attachment filepath does not support token reference Hi, Thank you for the reply! So the BUILD_NUMBER token is not allowed in the way I used it? Could you please suggest me the correct ANT pattern using the BUILD_NUMBER token? Yes, there are multiple rxzlog in the workspace (new rxzlog is created with every build). At the moment, I prefer to keep them all in the Reports folder. Therefore, I can't use path with *.rxzlog or similar wildcard. Have a nice day, Pavel 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
