[JIRA] (JENKINS-15150) Content is returned for HEAD requests when using gzip
Steffen Pingel commented on JENKINS-15150 Content is returned for HEAD requests when using gzip The example below is maybe more clear than the description. This violates the HTTP spec that states that the "server MUST NOT return a message-body in the response" for HEAD requests: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4. $ nc localhost 8080 HEAD /? HTTP/1.1 Accept-Encoding: gzip,deflate HTTP/1.1 200 OK Server: Winstone Servlet Engine v0.9.10 Content-Encoding: gzip Expires: 0 Cache-Control: no-cache,must-revalidate X-Hudson-Theme: default Content-Type: text/html;charset=UTF-8 X-Hudson: 1.395 X-Jenkins: 1.481 X-Jenkins-Session: 16e694bb X-Hudson-CLI-Port: 55248 X-Jenkins-CLI-Port: 55248 X-Jenkins-CLI2-Port: 55248 X-SSH-Endpoint: 127.0.0.1:38694 Content-Length: 3750 Connection: Keep-Alive Date: Thu, 13 Sep 2012 06:09:02 GMT X-Powered-By: Servlet/2.5 (Winstone/0.9.10) Set-Cookie: JSESSIONID.e8d41638=2a67514147fe0022332ef37297bd0dfd; Path=/; HttpOnly �Z�r�H���B��]6� ▒|oll���ey��Y�'۬]`�v73#�Tʫ2�Y�ѯ���ۧ~[��cſ▒ǿH�� ... The same happens when the Accept-Encoding header is not included. The difference is though that the server closes the connection (for whichever reason) so subsequent requests are likely to succeed. It would be better if the server kept the connection alive and returned a valid response. $ nc localhost 8080 HEAD /? HTTP/1.1 HTTP/1.1 200 OK Server: Winstone Servlet Engine v0.9.10 Expires: 0 Cache-Control: no-cache,must-revalidate X-Hudson-Theme: default Content-Type: text/html;charset=UTF-8 X-Hudson: 1.395 X-Jenkins: 1.481 X-Jenkins-Session: 16e694bb X-Hudson-CLI-Port: 55248 X-Jenkins-CLI-Port: 55248 X-Jenkins-CLI2-Port: 55248 X-SSH-Endpoint: 127.0.0.1:38694 Connection: Close Date: Thu, 13 Sep 2012 06:11:13 GMT X-Powered-By: Servlet/2.5 (Winstone/0.9.10) Set-Cookie: JSESSIONID.e8d41638=d616b2e4bd984bb32e675c49e87662ff; Path=/; HttpOnly !DOCTYPE htmlhtmlhead ... 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-15133) Provide CVS Plugin with Quiet and Really Quiet options
Michael Clarke closed JENKINS-15133 as Not A Defect Provide CVS Plugin with Quiet and Really Quiet options CVS Currently runs in Quiet mode with a checkbox on the job config screen to 'Show all CVS output' (i.e disable Quiet mode). A 'feature' of CVS is that it sends a lot of output through it's error stream (e.g. CVS Rlog: logging /path/to/directory), which could possibly be filtered before being put in the Jenkins console, but this is not controlled by the -Q/q flags Change By: Michael Clarke (13/Sep/12 7:26 AM) Status: Open Closed Assignee: MichaelClarke Resolution: NotADefect 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-14875) It takes aeons to delete large workspace on slow disks
Yury Pukhalsky edited a comment on JENKINS-14875 It takes aeons to delete large workspace on slow disks An observation. One of the nodes is on the NFS disk (btw, it's lnx10 from the previous comment), and clean-ws doesn't delete the files, albeit on the other nodes it does. The configuration is the same, it's matrix job. 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-14875) It takes aeons to delete large workspace on slow disks
Yury Pukhalsky commented on JENKINS-14875 It takes aeons to delete large workspace on slow disks An observation. One of the nodes is on the NFS disk, and clean-ws doesn't delete the files, albeit on the other nodes it does. The configuration is the same, it's matrix job. 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-13831) Need a way to copy empty directories with Publish Over SSH Plugin
Jörg Eichhorn commented on JENKINS-13831 Need a way to copy empty directories with Publish Over SSH Plugin Hi Ken, thanks for your helpful comments, I really appreciate your input! I've already had a look at the source to find the exact source fragment involved in this, but I was not successful on the first run. Maybe I find more time later. In the meantime I would appreciate any hints on which source files to start for this feature. 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-10961) All plugins are not available
evernat resolved JENKINS-10961 as Not A Defect All plugins are not available sogabe is right: those are not jenkins plugins. So this is not a defect. The list of available jenkins plugins is here: https://wiki.jenkins-ci.org/display/JENKINS/Plugins Change By: evernat (13/Sep/12 8:23 AM) Status: Open Resolved Resolution: NotADefect 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-15132) Cannot use a single file name as module for retrieval in CVS Plugin version 2.5
Michael Clarke commented on JENKINS-15132 Cannot use a single file name as module for retrieval in CVS Plugin version 2.5 Deepak: please confirm what you're seeing when it doesn't work. I suspect the first checkout works, but subsequent updates checkout all other files at the same level, and any subdirectories. Is this correct? 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-10972) Unable to authenticate with svn server (svn: OPTIONS /repo_name/svn/repo_name failed)
evernat commented on JENKINS-10972 Unable to authenticate with svn server (svn: OPTIONS /repo_name/svn/repo_name failed) The subversion plugin has changed quite a lot since v1.28: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin#SubversionPlugin-ChangeLog Do you reproduce the issue with a recent version of the 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-14884) Resume Stopped Ec2 Instances
Felix Geisendörfer commented on JENKINS-14884 Resume Stopped Ec2 Instances Wow, thank you so much. Will try this out right away! 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-13764) CVS authentication failure while running rlog command (Windows master / Unix slave)
Daniel Schaarschmidt commented on JENKINS-13764 CVS authentication failure while running rlog command (Windows master / Unix slave) Polling is enabled, but when I tried with the new CVS-Plugin-Version I manually triggered the build for testing purposes, so I'm not sure whether polling would have worked or not. Because this behaviour is a showstopper for us, I went back to version 1.6. I'll have another go with the current version next week to test polling. 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-15151) Add Support for Mailing upstream committers when the build fails
Jason Spotswood created JENKINS-15151 Add Support for Mailing upstream committers when the build fails Issue Type: New Feature Assignee: mdonohue Components: configurationslicing Created: 13/Sep/12 9:00 AM Description: Enable (or disable) the "Post Build Action" "Mailing upstream committers when the build fails" via the configuration slicer plugin. This feature is provided via the "Blame Upstream Committers" plugin. Project: Jenkins Labels: plugin configuration Priority: Minor Reporter: Jason Spotswood 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-14884) Resume Stopped Ec2 Instances
Felix Geisendörfer commented on JENKINS-14884 Resume Stopped Ec2 Instances Just tried it out and it seems to work perfectly! This is absolutely awesome! Thank you so much. 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-15137) DUnit support request
nahumba nahumba commented on JENKINS-15137 DUnit support request I have no technical idea how to do the integration. As user expirience it would be nice to be able to run the dunit application after the main build. To let the dunit run, as it produce an xml file. parse that Xml file for success fail and exceptions. and return error for fail or exception, and success on successes. An Xml example, or even better the open-source code of dunit object "TXMLTestListener" from XMLTestRunner.pas could be provided. 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-15137) DUnit support request
nahumba nahumba edited a comment on JENKINS-15137 DUnit support request I have no technical idea how to do the integration. As user expirience it would be nice to be able to run the dunit application after the main build. To let the dunit run, as it produce an xml file. parse that Xml file for success fail and exceptions. and return error for fail or exception, and success on successes. An Xml example, or even better the open-source code of dunit object "TXMLTestListener" from XMLTestRunner.pas could be provided. link: http://www.koders.com/delphi/fidEF3CCC691E55718B74B420D9C1150399D677B5D4.aspx?s=pos#L249 xmlformat : main branch is ?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ? TestRun TestSuite name="First" TestSuite name="Second" TestSuite name="Third" Test name="TestCheck" result="PASS"/Test Test name="SecondTestCheck" result="PASS"/Test Statistics Stat name="Tests" result="2" / Stat name="Failures" result="0" / Stat name="Errors" result="0" / Stat name="Success Rate" result="100%" / Stat name="Finished At" result="12/09/2004 10:00:00" / Stat name="Runtime" result="00:00:03" / /Statistics /TestRun 3 functions for success error failure: procedure AddSuccess(test: ITest); virtual; procedure AddError(error: TTestFailure); virtual; procedure AddFailure(failure: TTestFailure); virtual; produce xml: success: 'Test name="'test.GetName'" result="PASS"/Test error: 'Test name="'error.FailedTest.GetName'" result="ERROR"' 'FailureType'error.ThrownExceptionName'/FailureType' 'Location'error.LocationInfo'/Location' 'Message'text2sgml(error.ThrownExceptionMessage)'/Message' '/Test' failure: 'Test name="'failure.FailedTest.GetName'" result="FAILS"'+ 'FailureType'failure.ThrownExceptionName'/FailureType'+ 'Location'failure.LocationInfo'/Location'+ 'Message'text2sgml(failure.ThrownExceptionMessage)'/Message'+ '/Test' if you could provide the current interface for one of the xUnit testing i could create a new DUnit file and publish it under the license of the DUnit. as it seem to used here: http://stackoverflow.com/questions/4488203/dunit-test-result-messages-in-hudson 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-13831) Need a way to copy empty directories with Publish Over SSH Plugin
bap commented on JENKINS-13831 Need a way to copy empty directories with Publish Over SSH Plugin I have a solution for this - it will just take a week or two for me to fit it into my backlog. In the mean time can you use the decades old trick of zero length hidden files? i.e. touch .keep in any leaf directory that yo want to be present on the target machine. (you can even use find in the Exec command to remove them afterwards if you need the dirs to be completely empty) Alternatively keep zipping until a new version is released. 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-14721) 500 error switching to Pegdown
bap closed JENKINS-14721 as Fixed 500 error switching to Pegdown Change By: bap (13/Sep/12 10:03 AM) Status: Resolved Closed 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-14283) Publish Over FTP - as Build Step
bap closed JENKINS-14283 as Fixed Publish Over FTP - as Build Step Change By: bap (13/Sep/12 10:04 AM) Status: Resolved Closed 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-14068) Mark build unstable does not work
bap closed JENKINS-14068 as Not A Defect Mark build unstable does not work Change By: bap (13/Sep/12 10:05 AM) Status: Resolved Closed 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-13693) Add DefaultExcludes boolean option to transfer set
bap closed JENKINS-13693 as Fixed Add DefaultExcludes boolean option to transfer set Change By: bap (13/Sep/12 10:06 AM) Status: Resolved Closed 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-13795) NPE with Flexible Publisher job
bap closed JENKINS-13795 as Fixed NPE with Flexible Publisher job Change By: bap (13/Sep/12 10:05 AM) Status: Resolved Closed 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-15037) Option to consider only stable builds when calculating new warnings
David Pärsson edited a comment on JENKINS-15037 Option to consider only stable builds when calculating new warnings Hm.. What should happen when a project has different warning priorities and one of them increases and another decreases? Ideally when this new option would be enabled, I wouldn't want to decrease any reference warning count for any priority. Using a single build as reference build would however not allow this, and this might complicate things even further. I think it's more clear to just use the stable build as a reference, and ignore the fact that deltas might get messed up as stated in my comment above. 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-15037) Option to consider only stable builds when calculating new warnings
David Pärsson commented on JENKINS-15037 Option to consider only stable builds when calculating new warnings Hm.. What should happen when a project has different warning priorities and one of them increases and another decreases? Ideally when this new option would be enabled, I wouldn't want to decrease any reference warning count for any priority. Using a single build as reference build would however not allow this, and this might complicate things even further. I think it's more clear to just use the stable build as a reference, and ignore the fact that deltas might get messed up as stated in my comment above. 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-15139) Add ability to handle command line arguments in valgrind runner
Johannes Ohlemacher commented on JENKINS-15139 Add ability to handle command line arguments in valgrind runner adding command line options for the program under test is on my todo list for quite some time, just give me a few more days. thanks for the feedback! btw: the runner prints the call to valgrind to the log (including all valgrind command line options), so if you want to run valgrind by yourself (from your Makefile or whatever) and you miss some meta data, take a look at it! maybe you just missed some options!? 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-15153) Custom logging template
Christian Wolfgang created JENKINS-15153 Custom logging template Issue Type: New Feature Assignee: Christian Wolfgang Components: logging Created: 13/Sep/12 10:35 AM Description: It is currently not possible to modify the logging template. It should be! Project: Jenkins Priority: Minor Reporter: Christian Wolfgang 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-15037) Option to consider only stable builds when calculating new warnings
Ulli Hafner commented on JENKINS-15037 Option to consider only stable builds when calculating new warnings I think if the checkbox is set then an unstable build should be completely ignored. 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-15109) Stacktrace introduced in 1.481 when going to http://jenkins /computer/(master)/api/xml
Marc Günther commented on JENKINS-15109 Stacktrace introduced in 1.481 when going to http://jenkins /computer/(master)/api/xml Seems to be caused by: https://github.com/aerickson/jenkins/commit/cad57430c2b005698fc494d30d67c091a30e5dee#L0R252 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-15154) Cannot delete workspace
Gossé Romain created JENKINS-15154 Cannot delete workspace Issue Type: Bug Affects Versions: current Assignee: Deluan Quintão Components: rtc Created: 13/Sep/12 12:39 PM Description: When trying to delete the workspace, I got this exception: java.io.IOException: Cannot run program "scm": CreateProcess error=2, The system cannot find the file specified java.lang.ProcessBuilder.start(ProcessBuilder.java:460) hudson.Proc$LocalProc.init(Proc.java:244) hudson.Proc$LocalProc.init(Proc.java:216) hudson.Launcher$LocalLauncher.launch(Launcher.java:707) hudson.Launcher$ProcStarter.start(Launcher.java:338) com.deluan.jenkins.plugins.rtc.JazzClient.joinWithPossibleTimeout(JazzClient.java:162) com.deluan.jenkins.plugins.rtc.JazzClient.stopDaemon(JazzClient.java:93) com.deluan.jenkins.plugins.rtc.JazzSCM.processWorkspaceBeforeDeletion(JazzSCM.java:136) hudson.model.AbstractProject.doDoWipeOutWorkspace(AbstractProject.java:1762) Looking at the code I understand that lscm.bat (which I set) does not support this operation. It should fail in a nicer way, possibly carrying on with the wiping of the workspace. Also, I tried setting another command line tool (I don't seem to have a scm.bat, but I do have an scm.exe) with the same result. Environment: windows, rtc plugin 0.3, Jenkins 1.435 Project: Jenkins Priority: Major Reporter: Gossé Romain 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-15154) Cannot delete workspace
Romain Gossé commented on JENKINS-15154 Cannot delete workspace That blocks the deletion of the build plan itself. 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-14896) java.io.FileNotFoundException when saving module data
Sega edited a comment on JENKINS-14896 java.io.FileNotFoundException when saving module data Yep, you are right. the full path need to be also for the "Class directory" and "Source directory" columns. I recommend you to add more error/debug messages with explanations, It's makes life easier for the end user troubleshooting. Ok now its working But now the "Coverage Breakdown by Module" and the total result tables graphics look weird (text exceeds the limit of the column). 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-14896) java.io.FileNotFoundException when saving module data
Sega edited a comment on JENKINS-14896 java.io.FileNotFoundException when saving module data The Jacoco .exec file full structure path is: "target/jacoco/jacoco.exec". "jacoco.exec" file is in "module/target/jacoco" folder. 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-14896) java.io.FileNotFoundException when saving module data
Sega edited a comment on JENKINS-14896 java.io.FileNotFoundException when saving module data Thanks Ognjen One more question please: After the Jacoco plugin successfully finished to collect the modules data (*.exec) and the build successfully finished, I go back to my Jenkins Job - last Build - "Coverage Report" and on this screen all the column with 0.0% M:0 C: 0 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-15155) Show total number of tests in test column
Sebastian Schuberth created JENKINS-15155 Show total number of tests in test column Issue Type: Improvement Affects Versions: current Assignee: Fred G Components: extra-columns Created: 13/Sep/12 1:31 PM Description: Please also show the total number of tests that have executed as part of the test columns. A statement "0 failed tests" is misleading when the test suite crashes and only e.g. 1 out of 50 tests executed (and that 1 test succeeded). Environment: Jenkins 1.480 Project: Jenkins Priority: Minor Reporter: Sebastian Schuberth 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-14896) java.io.FileNotFoundException when saving module data
Ognjen Bubalo commented on JENKINS-14896 java.io.FileNotFoundException when saving module data If you have more problems with this issue please write a summary and post a printscreen, so the thread will be more readable. 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-15129) Create or Update Label in Perforce doesn't access build parameters.
Rob Petti resolved JENKINS-15129 as Not A Defect Create or Update Label in Perforce doesnt access build parameters. Change By: Rob Petti (13/Sep/12 2:15 PM) Status: Open Resolved Resolution: NotADefect 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-15156) Builds Disappear from Build History after Completion
bbonn created JENKINS-15156 Builds Disappear from Build History after Completion Issue Type: Bug Assignee: Unassigned Components: other Created: 13/Sep/12 2:20 PM Description: We have recently noticed builds disappearing from the "Build History" listing on the project page. Developer was watching a build, waiting for it to complete and said it disappeared after it finished. Nothing was noted in any of the logs concerning that build. The data was still present on the disk and doing a reload from disk brought the build back. We have other automated jobs that deploy these builds based on build number, so it is pretty big issue in our environment. We are not able to reproduce at this point, but I still wanted to document what was happening. I have seen other JIRA issues that look similar, but in those jobs were disappearing after a restart, or upgrade. That is not the case for us. The build disappears after completion, success or failure. Environment: Jenkins 1.477.2 Master and Slaves Windows Server 2008 r2 Project: Jenkins Priority: Major Reporter: bbonn 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-15154) Cannot delete workspace
Romain Gossé commented on JENKINS-15154 Cannot delete workspace Workaround: putting scm on the PATH. 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-15158) Sometimes starts the wrong instance
Quentin Hartman created JENKINS-15158 Sometimes starts the wrong instance Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: ec2 Created: 13/Sep/12 2:47 PM Description: Relevant configuration - I have one cloud setup, with 4 different AMIs defined. They are each technically identical, the only difference being that they have different Jenkins labels so that certain builds only happen on a certain machine. Let's call them A, B, C, and D. Expected behavior - If all build hosts are stopped and I start a build for project B, only the build host for project B will start. Actual behavior - If all the build hosts are stopped, and I start a build for project B, the A build host is started first, and once that is up, the B build host is started, and once that is up the B project starts building on it as expected. This introduces a longer than expected delay when starting builds. Project: Jenkins Priority: Major Reporter: Quentin Hartman 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-15157) Failure in @DataProvider method is not reported and build stays SUCCESS
Ruslan Makhmudau created JENKINS-15157 Failure in @DataProvider method is not reported and build stays SUCCESS Issue Type: Bug Assignee: kutzi Components: junit Created: 13/Sep/12 2:47 PM Description: Occasionally we have some test which lets Surefire fail hard which Hudson doesn't recognize. I.e. the tests are not executed, but the build result is still success. E.g. we had a test which failed with a NoSuchFieldException in the constructor of the test class: Running TestSuite log4j:WARN No appenders could be found for logger (...). log4j:WARN Please initialize the log4j system properly. org.apache.maven.surefire.booter.SurefireExecutionException: Cannot instantiate class XyzTest; nested exception is org.testng.TestNGException: Cannot instantiate class XyzTest org.testng.TestNGException: Cannot instantiate class XyzTest at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:35) at org.testng.internal.ClassHelper.createInstance(ClassHelper.java:330) at org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:62) at org.testng.internal.ClassImpl.getInstances(ClassImpl.java:81) at org.testng.internal.TestNGClassFinder.init(TestNGClassFinder.java:114) at org.testng.TestRunner.initMethods(TestRunner.java:289) at org.testng.TestRunner.init(TestRunner.java:235) at org.testng.TestRunner.init(TestRunner.java:197) at org.testng.TestRunner.init(TestRunner.java:141) at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:488) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:250) at org.testng.SuiteRunner.run(SuiteRunner.java:204) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:877) at org.testng.TestNG.runSuitesLocally(TestNG.java:842) at org.testng.TestNG.run(TestNG.java:751) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:26) ... 23 more Caused by: java.lang.NoSuchFieldException: cipherService at java.lang.Class.getDeclaredField(Class.java:1882) at XyzTest.init(XyzTest.java:91) ... 28 more ERROR There are test failures. Environment: Hudson 1.351, Maven 2.2.1, Surefire 2.5, TestNG 5.9 Jenkins 1.420 Project: Jenkins Priority: Critical Reporter: Ruslan Makhmudau 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:
[JIRA] (JENKINS-15157) Failure in @DataProvider method is not reported and build stays SUCCESS
Wise updated JENKINS-15157 Failure in @DataProvider method is not reported and build stays SUCCESS Change By: Wise (13/Sep/12 2:51 PM) Assignee: kutzi nalin_makar Environment: Hudson1.351,Maven2.2.1,Surefire2.5, TestNG5.9Jenkins1. 420 478 Priority: Critical Major Description: OccasionallywehavesometestwhichletsSurefirefailhardwhichHudsondoesntrecognize. I .e. got the testsarenotexecuted followingexceptionDuringthe@DataProviderMethod ,but Jenkkinsdoesntfail thebuild resultisstillsuccess.E.g.wehadatestwhichfailedwithaNoSuchFieldExceptionintheconstructorofthetestclass : RunningTestSuitelog4j:WARNNoappenderscouldbefoundforlogger(...).log4j:WARNPleaseinitializethelog4jsystemproperly.org.apache.maven.surefire.booter.SurefireExecutionException:CannotinstantiateclassXyzTest;nestedexceptionisorg.testng.TestNGException:CannotinstantiateclassXyzTestorg.testng.TestNGException:CannotinstantiateclassXyzTest atorg.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl. java :35) atorg . testng.internal.ClassHelper.createInstance(ClassHelper.java:330) atorg.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:62) atorg.testng.internal.ClassImpl.getInstances(ClassImpl.java:81) atorg.testng.internal.TestNGClassFinder.init(TestNGClassFinder.java:114) atorg.testng.TestRunner.initMethods(TestRunner.java:289) atorg.testng.TestRunner.init(TestRunner.java:235) atorg.testng.TestRunner.init(TestRunner.java:197) atorg.testng.TestRunner.init(TestRunner.java:141) atorg.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:488) atorg.testng.SuiteRunner.privateRun(SuiteRunner.java:250) atorg.testng.SuiteRunner.run(SuiteRunner.java:204) atorg.testng.TestNG.createAndRunSuiteRunners(TestNG.java:877) atorg.testng.TestNG.runSuitesLocally(TestNG.java:842) atorg.testng.TestNG.run(TestNG.java:751) atorg.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62) atorg.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141) atorg.apache.maven.surefire.Surefire.run(Surefire.java:180) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) atjava. lang. reflect.Method.invoke(Method.java RuntimeException : 597) atorg.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter. java :350) atorg . apache io . maven.surefire.booter.SurefireBooter.main(SurefireBooter.java FileNotFoundException : 1021)Causedby:java TestData\www . lang.reflect.InvocationTargetException atsun.reflect.NativeConstructorAccessorImpl.newInstance0 xls ( NativeMethod Thesystemcannotfindthepathspecified ) atsun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) atsun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) atjava.lang.reflect.Constructor.newInstance(Constructor.java:513) atorg.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:26) ...23moreCausedby:java.lang.NoSuchFieldException:cipherService atjava.lang.Class.getDeclaredField(Class.java:1882) atXyzTest.init(XyzTest.java:91) ...28more[ERROR]Therearetestfailures. Component/s: testng Component/s: junit 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-15158) Sometimes starts the wrong instance
Quentin Hartman commented on JENKINS-15158 Sometimes starts the wrong instance I've now also tried starting a build for project D, and that also starts build host for A first, then the appropriate host. In the plugin config the AMIs are listed in order A-D, so it does not look like a list traversal bug where it is starting at A and going down the list until the right one is found. It seems it just always wants to start the first one, no matter what. 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-13594) Ampersand in execute shell build step; SEVERE: Error parsing body of the request
Cory Wright commented on JENKINS-13594 Ampersand in execute shell build step; SEVERE: Error parsing body of the request This seems to still be an issue. In my execute shell I want to run something like this: ssh 127.0.0.1 "cd dir git pull origin master ./build.sh" The double ampersands are preventing jenkins from saving the configuration. If I change the to semicolins then everything works. 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-15148) OpenIndiana IPS package has permissions conflict with oi_151a6
A Hettinger commented on JENKINS-15148 OpenIndiana IPS package has permissions conflict with oi_151a6 I looked into this some more, but found that pkgrecv would not work against this repo. I convinced a couple guys who know more about the internals of IPS then myself to look at it, and they found the repo's responses in general to be surprising. (to the point of questioning if this was a truly depotd). At any rate, they where able to confirm our suspicions that just removing the reference to var/lib from the manifest should work fine. 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-15146) EnvJect unsets empty string properties returned in maps
Jeff Maxwell commented on JENKINS-15146 EnvJect unsets empty string properties returned in maps We need to blank a variable (a perforce label) based on certain combinations of user input. 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-15097) Expecting integer when it can be a float or even a string
SCM/JIRA link daemon commented on JENKINS-15097 Expecting integer when it can be a float or even a string Code changed in jenkins User: Ryan Campbell Path: src/main/java/hudson/plugins/android_emulator/util/Utils.java src/test/java/hudson/plugins/android_emulator/util/UtilsTest.java http://jenkins-ci.org/commit/android-emulator-plugin/8a76be5b8244a6735817916dcb32a0631d853ce8 Log: JENKINS-15097 Deal with crazy android version strings 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-15097) Expecting integer when it can be a float or even a string
SCM/JIRA link daemon commented on JENKINS-15097 Expecting integer when it can be a float or even a string Code changed in jenkins User: Christopher Orr Path: src/main/java/hudson/plugins/android_emulator/util/Utils.java src/test/java/hudson/plugins/android_emulator/util/UtilsTest.java http://jenkins-ci.org/commit/android-emulator-plugin/446247837b2bb4f72f6395e747b0f40232331a72 Log: Merge pull request #15 from recampbell/master JENKINS-15097 Deal with crazy android version strings Compare: https://github.com/jenkinsci/android-emulator-plugin/compare/bcb357881bcf...446247837b2b 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
FireFart commented on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. same problem here. 1.13 fixes the problem so this bug was intrudiced in 1.14 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-15139) Add ability to handle command line arguments in valgrind runner
SCM/JIRA link daemon commented on JENKINS-15139 Add ability to handle command line arguments in valgrind runner Code changed in jenkins User: Johannes Ohlemacher Path: src/main/java/org/jenkinsci/plugins/valgrind/ValgrindBuilder.java src/main/resources/org/jenkinsci/plugins/valgrind/ValgrindBuilder/config.jelly http://jenkins-ci.org/commit/valgrind-plugin/17bef8c049d3eb525dd66c6436d326964a2a7888 Log: added support for arbitrary valgrind options (JENKINS-15139) added support for program options (JENKINS-15138) 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-15138) Add ability to specify valgrind command line options to plugin configuration
SCM/JIRA link daemon commented on JENKINS-15138 Add ability to specify valgrind command line options to plugin configuration Code changed in jenkins User: Johannes Ohlemacher Path: src/main/java/org/jenkinsci/plugins/valgrind/ValgrindBuilder.java src/main/resources/org/jenkinsci/plugins/valgrind/ValgrindBuilder/config.jelly http://jenkins-ci.org/commit/valgrind-plugin/17bef8c049d3eb525dd66c6436d326964a2a7888 Log: added support for arbitrary valgrind options (JENKINS-15139) added support for program options (JENKINS-15138) 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-3963) JDK auto install from j.s.c need to be able to specify 32bit/64bit
Michael Chmielewski commented on JENKINS-3963 JDK auto install from j.s.c need to be able to specify 32bit/64bit I have an environment where this would be a boon. We have some jobs that will only work with a 32-bit JDK, though generally we want to use the 64-bit JDKs. 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
Deployment issue using Jenkins.
We're on Jenkins 1.409 Running on 32-bit WAS 6.1.0.39 on AIX 6.1. We installed the latest version of the was-builder.hpi to support WAS8 deployments. We are getting the following error while deploying/updating an ear file to WAS8 env via Jenkins: exception information: com.ibm.websphere.management.application.client.AppDeploymentException: AppDeploymentException: [] org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescriptorLoadException: dd_in_ear_load_EXC_ org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescriptorLoadException: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescriptorLoadException: dd_in_ear_load_EXC_ When we try to upload the same ear through a WAS6.1 admin console (jdk 1.5 32-bit), the upload fails with the same message as above. However we are able to successfully upload and deploy the same ear file in WAS7 admin console ( jdk 1.6 64-bit) and WAS8 admin console( jdk 1.6 64-bit). We can also deploy it to WAS8 using the same wsadmin command used in Jenkins, from the command line on the WAS8 server. This proves that the ear file is correctly validated for jdk6. Can someone please help understand why we see this message in Jenkins and help find a solution? -- View this message in context: http://jenkins.361315.n4.nabble.com/Deployment-issue-using-Jenkins-tp4640163.html Sent from the Jenkins issues mailing list archive at Nabble.com.
Error while deploying to Message Broker
I have an ant build script that will build and deploy the bar file to a broker. Wehn I execute the ant file from cmd promp both actions are successful. BUt when I try to invoke that ant script from Jenkins I am seeing below exeption. Can anybosy please help. I am stuck , no clue where to look for the exact error. I checked the QMGR logs , broker logs. Could not find any exceptions. - MQSI 7.0.0.0 C:\Program Files (x86)\IBM\MQSI\7.0 BIP1044I: Connecting to the queue manager... BIP1046E: Unable to connect with the queue manager (com.ibm.mq.MQQueueManager). The utility encountered a problem while attempting to connect to the queue manager to put a message to the broker's request queue. Ensure that the correct connection parameters have been supplied to the utility. Also ensure that the queue manager is running and that the current user is able to access the queues beginning SYSTEM.BROKER. If this error text includes an MQ reason code, look up the meaning behind the error in the Application Programming Reference guide and proceed as appropriate. Build step 'Execute Windows batch command' marked build as failure Finished: FAILURE .http://jenkins.361315.n4.nabble.com/Error-while-deploying-to-Message-Broker-td4640164.html#http://www.nabble.com/
[JIRA] (JENKINS-14638) Update documentation links
wolfs started work on JENKINS-14638 Update documentation links Change By: wolfs (13/Sep/12 7:40 PM) Status: Open InProgress 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-14638) Update documentation links
SCM/JIRA link daemon commented on JENKINS-14638 Update documentation links Code changed in jenkins User: Stefan Wolf Path: src/main/resources/org/jvnet/hudson/plugins/groovypostbuild/GroovyPostbuildRecorder/help.jelly http://jenkins-ci.org/commit/groovy-postbuild-plugin/c4a8e57bd46d0dba232f61ff9f3e61d97524a503 Log: FIXED JENKINS-14638 Added links to API and updated Hudson to Jenkins Compare: https://github.com/jenkinsci/groovy-postbuild-plugin/compare/69cf1ec1ed96...c4a8e57bd46d 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-14638) Update documentation links
SCM/JIRA link daemon resolved JENKINS-14638 as Fixed Update documentation links Change By: SCM/JIRA link daemon (13/Sep/12 7:48 PM) Status: InProgress 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-15159) OutOfMemoryException on launching slave
Krzysztof Malinowski created JENKINS-15159 OutOfMemoryException on launching slave Issue Type: Bug Assignee: Unassigned Components: core Created: 13/Sep/12 8:09 PM Description: OutOfMemoryException during slave connection. When connecting slave through SSH: 09/13/12 21:56:30 SSH Checking java version of java 09/13/12 21:56:30 SSH java -version returned 1.6.0_24. 09/13/12 21:56:30 SSH Starting sftp client. 09/13/12 21:56:30 SSH Copying latest slave.jar... 09/13/12 21:56:30 SSH Copied 278,201 bytes. 09/13/12 21:56:30 SSH Starting slave process: cd '/dev/shm/cp_hudson' java -jar slave.jar ===JENKINS REMOTING CAPACITY===channel started Slave.jar version: 2.17 This is a Unix slave ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins. java.lang.OutOfMemoryError: getNewTla at java.util.HashMap.addEntry(HashMap.java:937) at java.util.HashMap.put(HashMap.java:477) at java.util.HashSet.add(HashSet.java:200) at java.io.ObjectStreamClass$FieldReflector.init(ObjectStreamClass.java:1852) at java.io.ObjectStreamClass.getReflector(Unknown Source) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:459) at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:308) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:545) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ERROR: Connection terminated 09/13/12 21:56:32 SSH Connection closed. java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ERROR: 09/13/12 21:56:32 slave agent was terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) When accepting connection from JNLP client: INFO: Accepted connection #10 from /xx.xx.xx.82:2652 Exception in thread "TCP slave agent connection handler #10 with /xx.xx.xx.82:2652" java.lang.OutOfMemoryError: getNewTla at java.util.HashMap.addEntry(HashMap.java:937) at java.util.HashMap.put(HashMap.java:477) at java.util.HashSet.add(HashSet.java:200) at java.io.ObjectStreamClass$FieldReflector.init(ObjectStreamClass.java:1852) at java.io.ObjectStreamClass.getReflector(Unknown Source) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:459) at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:308) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:545) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at
Re: [JIRA] (JENKINS-15130) BuildTrigger ambiguous
Which version did you upgrade Jenkins from? -- View this message in context: http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-15130-BuildTrigger-ambiguous-tp4639987p4640173.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-1348) Workspace is offline triggers a build
Joe Hansche commented on JENKINS-1348 Workspace is offline triggers a build @Brian: The git plugin does support a "fast remote polling", using the git ls-remote command, which allows fetching the latest revisions from the remote URL without actually requiring a workspace to keep an entire clone of the repository. That then only requires that the git plugin keep track of the last built revisions, and if the revision doesn't match, it would trigger a new build. That said, the git plugin currently does not appear to save this option properly, as every time I check that box, it appears to get lost the next time I look at the configuration. The really annoying part of this behavior is that the SCM poller is already starting to do work before the slaves even have a chance to come online (for persistent slaves). So pretty much every restart of Jenkins in my experience, causes all SCM polling jobs to schedule new builds, even though nothing changed and there's no reason to start a build. That has the downside that all my slaves are hosed for at least 5-10 minutes after a startup. To make matters worse, using the "Purge Build Queue" plugin to clear out the build queue on startup, actually does more harm than good, because it appears to leave the SCM pollers in an unstable state, and eventually one or more slaves seems to become unresponsive, and it's just a cascading effect from there. 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-15105) Signature in hudson.tasks.Maven.MavenInstaller.json causes NullPointerException
SCM/JIRA link daemon commented on JENKINS-15105 Signature in hudson.tasks.Maven.MavenInstaller.json causes NullPointerException Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/model/DownloadService.java war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/ad61369d7b4c774db4fe3606cc71dfad797bf49f Log: JENKINS-15105 Prefer the postMessage version to retrieve the metadata so that we can leave the existing JSON format as-is for backward compatibility with pre-1.424 Jenkins. (cherry picked from commit f3701da9e215abeaadef39c1f47021cb6e4d479b) Conflicts: 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
Gregory Boissinot started work on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. Change By: Gregory Boissinot (13/Sep/12 9:21 PM) Status: Open InProgress 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-10131) Git polling shouldn't need a workspace on a slave.
Joe Hansche commented on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Nicolas De Loof: What is the reason behind restricting the option to the simple case of single repo, single branch? git ls-remote can retrieve the full set of branches, and revisions for each, and then compare those branch revisions against the "last built revision" for each branch it is configured for. If any of them are different, then a build would be scheduled this is no different than what already happens with workspace polling, right? Another thing I don't understand, is how does it determine that it's not a single repo/single branch? That is, I'm using the multiple-scms plugin, and apparently that is causing the ls-remote option to be disabled automatically. But each instance of the GitSCM in my project contains only a single repo and a single branch, so why would that be failing? Multiple-SCMs should be able to isolate each of those separately, without considering it any more complex than a single repo, single branch. This behavior is a major problem for us, as we have the same problem that Christian reports in the first comment. We try to keep our master server free of builds, so that it can focus on its main task of "being the master." That means on restart, all of our jobs (well over 100) get scheduled immediately on startup, even though the slaves are actually coming online only seconds later. That is a huge waste of resources, and at times it actually causes the entire cluster to become unstable simply as a result of starting up! I'll look at modifying the ls-remote patch to see if I can get it to work with multiple branches, and also to find out why it behaves like this in the first place (since at least in my case, I actually don't have multiple branches). I just wanted to see if anyone else knows of some reason why what I said above could not work? 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
Gregory Boissinot commented on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. Strange behavior. Could you try with $SOURCE? And if the problem persists, please attach your job configuration file (config.xnl). 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-15139) Add ability to handle command line arguments in valgrind runner
Johannes Ohlemacher resolved JENKINS-15139 as Fixed Add ability to handle command line arguments in valgrind runner fixed with release 0.12 Change By: Johannes Ohlemacher (13/Sep/12 9:42 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-15138) Add ability to specify valgrind command line options to plugin configuration
Johannes Ohlemacher resolved JENKINS-15138 as Fixed Add ability to specify valgrind command line options to plugin configuration fixed with release 0.12 Change By: Johannes Ohlemacher (13/Sep/12 9:42 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-10131) Git polling shouldn't need a workspace on a slave.
Joe Hansche edited a comment on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Nicolas De Loof: What is the reason behind restricting the option to the simple case of single repo, single branch? git ls-remote can retrieve the full set of branches, and revisions for each, and then compare those branch revisions against the "last built revision" for each branch it is configured for. If any of them are different, then a build would be scheduled this is no different than what already happens with workspace polling, right? Another thing I don't understand, is how does it determine that it's not a single repo/single branch? That is, I'm using the multiple-scms plugin, and apparently that is causing the ls-remote option to be disabled automatically. But each instance of the GitSCM in my project contains only a single repo and a single branch, so why would that be failing? Multiple-SCMs should be able to isolate each of those separately, without considering it any more complex than a single repo, single branch. This behavior is a major problem for us, as we have the same problem that Christian reports in the first comment. We try to keep our master server free of builds, so that it can focus on its main task of "being the master." That means on restart, all of our jobs (well over 100) get scheduled immediately on startup, even though the slaves are actually coming online only seconds later. That is a huge waste of resources, and at times it actually causes the entire cluster to become unstable simply as a result of starting up! I'll look at modifying the ls-remote patch to see if I can get it to work with multiple branches, and also to find out why it behaves like this in the first place (since at least in my case, I actually don't have multiple branches). I just wanted to see if anyone else knows of some reason why what I said above could not work? EDIT: bah, nevermind :/ I just realized what was causing it now... I was so focused on the "single branch" criteria, that I didn't think to look at excluded regions and users, which many of my projects use to prevent re-triggering a build when a Jenkins job is responsible for auto publishing commits (publishing things like minified _javascript_ and CSS, and newly compiled Flash (swf) files). Removed those exclusions, and it works. I agree with the other feature request though, that this should be caught via the frontend before the user even clicks save, so that at least he knows why it won't work. 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-15105) Signature in hudson.tasks.Maven.MavenInstaller.json causes NullPointerException
dogfood commented on JENKINS-15105 Signature in hudson.tasks.Maven.MavenInstaller.json causes NullPointerException Integrated in jenkins_main_trunk #1927 JENKINS-15105 (Revision f3701da9e215abeaadef39c1f47021cb6e4d479b) Result = SUCCESS kohsuke : f3701da9e215abeaadef39c1f47021cb6e4d479b Files : war/src/main/webapp/scripts/hudson-behavior.js core/src/main/java/hudson/model/DownloadService.java 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
Glen Little commented on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. All my jobs stopped working too. Had to revert to 1.13. Sample "MSBuild Build File" entry: "%WORKSPACE%SvnBranchName%\site.sln" This uses a parameter from Jenkins and one defined in the project configuration itself. (Also, it would be nice if the tool could wrap "" marks around the full entry - if there are spaces in the result and if the "" are not already added!) 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
Glen Little edited a comment on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. All my jobs stopped working too. Had to revert to 1.13. Sample "MSBuild Build File" entry: "%WORKSPACE%SvnBranchName%\site.sln" This uses a parameter from Jenkins and one defined in the project configuration itself. (Also, it would be nice if the tool could wrap "" marks around the full entry - if there are spaces in the result and if the "" are not already added!) 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-15029) Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail.
Glen Little edited a comment on JENKINS-15029 Update of MSBuild plugin to 1.15 causes Parameterized trigger plugin to fail. All my jobs stopped working too. Had to revert to 1.13. Sample "MSBuild Build File" entry: "%WORKSPACE%\\%SvnBranchName%\site.sln" This uses a parameter from Jenkins and one defined in the project configuration itself. (Also, it would be nice if the tool could wrap "" marks around the full entry - if there are spaces in the result and if the "" are not already added!) 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-15161) Dashboard views use system time instead of Jenkins time
owenmehegan created JENKINS-15161 Dashboard views use system time instead of Jenkins time Issue Type: Bug Affects Versions: current Assignee: Peter Hayes Components: dashboard-view Created: 13/Sep/12 11:41 PM Description: I'm using the Dashboard View plugin and using the "latest builds" view. The system that Jenkins runs on has its clock set to UTC, but I have the Jenkins timezone set to PST. On all the native Jenkins pages, such as job build history, I see timestamps in PST. In the "latest builds" view the times are all UTC. I set the timezone for Jenkins by running it like this on the command line: java -Dorg.apache.commons.jelly.tags.fmt.timeZone=America/Los_Angeles -jar jenkins.war Environment: Linux Project: Jenkins Priority: Major Reporter: owenmehegan 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-15109) Stacktrace introduced in 1.481 when going to http://jenkins /computer/(master)/api/xml
Andrew Erickson commented on JENKINS-15109 Stacktrace introduced in 1.481 when going to http://jenkins /computer/(master)/api/xml Sorry about this. Fixed with https://github.com/jenkinsci/jenkins/pull/565. '/computer/(master)/api/xml' output below. when online: masterComputer displayNamemaster/displayName executor/ executor/ iconcomputer.png/icon idletrue/idle jnlpAgentfalse/jnlpAgent launchSupportedtrue/launchSupported loadStatistics/ manualLaunchAllowedtrue/manualLaunchAllowed monitorData hudson.node_monitors.SwapSpaceMonitor availablePhysicalMemory266338304/availablePhysicalMemory availableSwapSpace493879296/availableSwapSpace totalPhysicalMemory8581545984/totalPhysicalMemory totalSwapSpace2147483648/totalSwapSpace /hudson.node_monitors.SwapSpaceMonitor hudson.node_monitors.ArchitectureMonitorMac OS X (x86_64)/hudson.node_monitors.ArchitectureMonitor hudson.node_monitors.ResponseTimeMonitor average6/average /hudson.node_monitors.ResponseTimeMonitor hudson.node_monitors.TemporarySpaceMonitor path /private/var/folders/mj/rjhd11f10sx43t4np9xs5fb4gn/T /path size185129209856/size /hudson.node_monitors.TemporarySpaceMonitor hudson.node_monitors.DiskSpaceMonitor path/Users/aje/.jenkins/path size185129209856/size /hudson.node_monitors.DiskSpaceMonitor hudson.node_monitors.ClockMonitor diff0/diff /hudson.node_monitors.ClockMonitor /monitorData numExecutors2/numExecutors offlinefalse/offline offlineCauseReason/ temporarilyOfflinefalse/temporarilyOffline /masterComputer when offline: masterComputer displayNamemaster/displayName executor/ executor/ iconcomputer-x.png/icon idletrue/idle jnlpAgentfalse/jnlpAgent launchSupportedtrue/launchSupported loadStatistics/ manualLaunchAllowedtrue/manualLaunchAllowed monitorData hudson.node_monitors.SwapSpaceMonitor availablePhysicalMemory409993216/availablePhysicalMemory availableSwapSpace493879296/availableSwapSpace totalPhysicalMemory8583643136/totalPhysicalMemory totalSwapSpace2147483648/totalSwapSpace /hudson.node_monitors.SwapSpaceMonitor hudson.node_monitors.ArchitectureMonitorMac OS X (x86_64)/hudson.node_monitors.ArchitectureMonitor hudson.node_monitors.ResponseTimeMonitor average4/average /hudson.node_monitors.ResponseTimeMonitor hudson.node_monitors.TemporarySpaceMonitor path /private/var/folders/mj/rjhd11f10sx43t4np9xs5fb4gn/T /path size185130684416/size /hudson.node_monitors.TemporarySpaceMonitor hudson.node_monitors.DiskSpaceMonitor path/Users/aje/.jenkins/path size185130684416/size /hudson.node_monitors.DiskSpaceMonitor hudson.node_monitors.ClockMonitor diff0/diff /hudson.node_monitors.ClockMonitor /monitorData numExecutors2/numExecutors offlinetrue/offline offlineCause/ offlineCauseReason/offlineCauseReason temporarilyOfflinetrue/temporarilyOffline /masterComputer 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-15162) Unable to archive artifacts from JClouds Single-Use Slave
Adam Rofer created JENKINS-15162 Unable to archive artifacts from JClouds Single-Use Slave Issue Type: Bug Affects Versions: current Assignee: abayer Components: jclouds Created: 14/Sep/12 12:30 AM Description: When using the JClouds Single-Use Slave with a Maven project, it spools up and runs a Jenkins build just fine. Once it's done, I need to archive artifacts from that slave but I am unable to. I get: Archiving artifacts ERROR: No artifacts found that match the file pattern [valid pattern of files on slave]. Configuration error? Build step 'Archive the artifacts' changed build result to FAILURE Finished: FAILURE I explicitly run an "ls -la" of the folder/artifacts specified and they are indeed present before the slave is destroyed. I've also tried moving the Archive Artifacts into the "Post Build steps" via the Any Build Step Plugin but I get the same result. Jenkins.log does not have a stacktrace to help us. It's likely the plugin is in fact only looking on the Jenkins master for the files... Environment: Jclouds plugin 2.3, Jenkins 1.481 Project: Jenkins Priority: Major Reporter: Adam Rofer 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-9693) maven.build.timestamp.format is not obeyed in maven builds
Adam Rofer
commented on JENKINS-9693
maven.build.timestamp.format is not obeyed in maven builds
All of the above workarounds provide different timestamps in each submodule in a multi-module build. The only thing I managed to get working was the following code:
plugin
groupIdcom.github.goldin/groupId
artifactIdtimestamp-maven-plugin/artifactId
executions
execution
idset-specific-timestamp/id
goals
goaltimestamp/goal
/goals
phaseinitialize/phase
configuration
time{{
def newdate = null;
try {
newdate = Date.parse( "${maven.build.timestamp.format}", "${maven.build.timestamp}");
} catch (Exception e) {
newdate = Date.parse( "MMdd-HHmm", "${maven.build.timestamp}");
println "THANKS JENKINS, FOR JENKINS-9693";
}
newdate
}}/time
timestamp
propertyactual-timestamp/property
pattern${maven.build.timestamp.format}/pattern
/timestamp
/configuration
/execution
/executions
/plugin
...and then use actual-timestamp as your timestamp property.
This assumes you already have maven.build.timestamp.format set as a property.
Note that you can put whatever pattern you want in the pattern field, in this case it just formats it the way you originally wanted it
Also note that this will only reach minute resolution on Jenkins builds since that's what Jenkins munges it to.
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-9693) maven.build.timestamp.format is not obeyed in maven builds
Adam Rofer
edited a comment on JENKINS-9693
maven.build.timestamp.format is not obeyed in maven builds
All of the above workarounds provide different timestamps in each module in a multi-module build. The only thing I managed to get working was the following code:
plugin
groupIdcom.github.goldin/groupId
artifactIdtimestamp-maven-plugin/artifactId
executions
execution
idset-specific-timestamp/id
goals
goaltimestamp/goal
/goals
phaseinitialize/phase
configuration
time{{
def newdate = null;
try {
newdate = Date.parse( "${maven.build.timestamp.format}", "${maven.build.timestamp}");
} catch (Exception e) {
newdate = Date.parse( "MMdd-HHmm", "${maven.build.timestamp}");
println "THANKS JENKINS, FOR JENKINS-9693";
}
newdate
}}/time
timestamp
propertyactual-timestamp/property
pattern${maven.build.timestamp.format}/pattern
/timestamp
/configuration
/execution
/executions
/plugin
...and then use actual-timestamp as your timestamp property.
This assumes you already have maven.build.timestamp.format set as a property.
Note that you can put whatever pattern you want in the pattern field, in this case it just formats it the way you originally wanted it
Also note that this will only reach minute resolution on Jenkins builds since that's what Jenkins munges it to.
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-9693) maven.build.timestamp.format is not obeyed in maven builds
Adam Rofer
edited a comment on JENKINS-9693
maven.build.timestamp.format is not obeyed in maven builds
All of the above workarounds provide different timestamps in each module in a multi-module build. The only thing I managed to get working was the following code:
plugin
groupIdcom.github.goldin/groupId
artifactIdtimestamp-maven-plugin/artifactId
executions
execution
idset-specific-timestamp/id
goals
goaltimestamp/goal
/goals
phaseinitialize/phase
configuration
time{{
def newdate = null;
try {
newdate = Date.parse( "${maven.build.timestamp.format}", "${maven.build.timestamp}");
} catch (java.text.ParseException e) {
newdate = Date.parse( "MMdd-HHmm", "${maven.build.timestamp}");
println "THANKS JENKINS, FOR JENKINS-9693";
}
newdate
}}/time
timestamp
propertyactual-timestamp/property
pattern${maven.build.timestamp.format}/pattern
/timestamp
/configuration
/execution
/executions
/plugin
...and then use actual-timestamp as your timestamp property.
This assumes you already have maven.build.timestamp.format set as a property.
Note that you can put whatever pattern you want in the pattern field, in this case it just formats it the way you originally wanted it
Also note that this will only reach minute resolution on Jenkins builds since that's what Jenkins munges it to.
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-13701) Parameters lost on retry
Ben Ernst commented on JENKINS-13701 Parameters lost on retry From the looks of the change log, this seems to be fixed in version 1.8 Version 1.8 - June 12, 2012 new extension point to configure schedule delay fixed delay implementation parameter for build are reused on schedule limit for number of build attempts after 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-9879) Naginator Plugin: Add retry and retry-delay parameter
Ben Ernst resolved JENKINS-9879 as Fixed Naginator Plugin: Add retry and retry-delay parameter Judging by the changelog, this seems to be fixed Change By: Ben Ernst (14/Sep/12 1:43 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-2092) Additional Configuration Options for Naginator Plugin
Ben Ernst resolved JENKINS-2092 as Fixed Additional Configuration Options for Naginator Plugin this is fixed by the regular _expression_ condition Change By: Ben Ernst (14/Sep/12 1:44 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-2091) Add time delay to naginator
Ben Ernst resolved JENKINS-2091 as Fixed Add time delay to naginator this seems to be implemented Change By: Ben Ernst (14/Sep/12 1:44 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-15163) Mercurial plugin cloning not resolving environment variables correctly
Morgan Davis created JENKINS-15163 Mercurial plugin cloning not resolving environment variables correctly Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: mercurial Created: 14/Sep/12 2:26 AM Description: I am using an environment variable for my Kiln URL and specifying it in the mercurial section under source control. The environment variable is set and gets resolved in the shell when running the hg clone command. However, when the plugin checks if the URL matches what is already in the workspace, it checks against the configured URL before resolving the environment variable (which does not match what is in the hgrc of the workspace). This causes the job to clone every time it runs. Environment: x86_64 SuSE SLES 11 Project: Jenkins Priority: Major Reporter: Morgan Davis 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-15163) Mercurial plugin cloning not resolving environment variables correctly
Morgan Davis commented on JENKINS-15163 Mercurial plugin cloning not resolving environment variables correctly I am using the latest version of the mercurial plugin (1.41) with Jenkins Enterprise 12.05. 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
