[JIRA] (JENKINS-15932) Slave hangs
dmatag created JENKINS-15932 Slave hangs Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: slaveSystemInfo.txt, threadDump.txt Components: slave-status Created: 27/Nov/12 7:51 AM Description: Slave hangs after archiving (or not archiving). The last message is "[JENKINS] Archiving disabled - not archiving /slavejenkins/workspace/IPTBFUBLKEKYC/pom.xml" Due Date: 19/Nov/12 12:00 AM Project: Jenkins Priority: Major Reporter: dmatag 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-15931) Build is hanging on newly created EC2 slaves
Hiroko Tamagawa assigned JENKINS-15931 to Unassigned Build is hanging on newly created EC2 slaves Change By: Hiroko Tamagawa (27/Nov/12 5:21 AM) Assignee: Francis Upton 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-15931) Build is hanging on newly created EC2 slaves
Hiroko Tamagawa created JENKINS-15931 Build is hanging on newly created EC2 slaves Issue Type: Bug Assignee: Francis Upton Components: ec2, xunit Created: 27/Nov/12 4:15 AM Description: When using Amazon EC2 plugin, builds on newly created EC2 instances sometimes hang. We have two permanent slaves for a certain label (e.g. 'unittest'), which is generated from an AMI. The same AMI is specified within Amazon EC2 plugin settings. We have a job which can be executed concurrently When we invoke three builds at one time, two permanent slaves are exhausted and the new one is created. The problem is that the build on the new slave hangs at the end of it where xUnit plugin is aggregating the test result. [CHECKSTYLE] Collecting checkstyle analysis files... [CHECKSTYLE] Computing warning deltas based on reference build #850 [FINDBUGS] Collecting findbugs analysis files... [FINDBUGS] Computing warning deltas based on reference build #850 Archiving artifacts [xUnit] [INFO] - Starting to record. [xUnit] [INFO] - Processing JUnit [xUnit] [INFO] - [JUnit] - 581 test report file(s) were found with the pattern '**/testresult/**/*.xml' relative to '/var/lib/jenkins/workspace/400_Precommit_Check_Branch' for the testing framework 'JUnit'. After aborting the build, the following error is shown. ERROR: Publisher org.jenkinsci.plugins.xunit.XUnitPublisher aborted due to exception java.lang.InterruptedException at java.lang.Object.wait(Native Method) at hudson.remoting.Request.call(Request.java:146) at hudson.remoting.Channel.call(Channel.java:665) at hudson.FilePath.act(FilePath.java:841) at hudson.FilePath.act(FilePath.java:825) at org.jenkinsci.plugins.xunit.XUnitPublisher.performTests(XUnitPublisher.java:170) at org.jenkinsci.plugins.xunit.XUnitPublisher.performXUnit(XUnitPublisher.java:115) at org.jenkinsci.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:92) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:779) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726) at hudson.model.Run.execute(Run.java:1541) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Email was triggered for: Failure Sending email for trigger: Failure I tried to capture the thread dump, but both master and the target slave had EMPTY thread dump while another slave had its own. I'd appreciate if someone give me advice. Jenkins ver. 1.491 xUnit plugin 1.51 Amazon EC2 plugin 1.17 Project: Jenkins Priority: Major Reporter: Hiroko Tamagawa 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system It works with the second one removed. Tomorrow I can try adding a second one via the UI, save, and then come back to the page to see if the issue remains. 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system I'll give that a shot tomorrow morning, sure... 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Bao Xiaopan(Bob) edited a comment on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing @Oresztesz Margaritisz Pls upgrade your Jenkins and Subversion plugin both to the latest version, I've tested your case on my Jenkins server with Jenkins ver. 1.491 and Subversion Plug-in ver. 1.43 , and it works perfectly. See my output, in my example, I set 3 svn url in the subversion plugin, and run "env" command in the shell step, it has a very clear output of 3 SVN_URL and 3 SVN_REVISION: [test] $ /bin/sh -xe /tmp/hudson4800466824911128402.sh + env BUILD_URL=http://jenkins.xxx-inc.com:8080/job/test/100/ BUILD_CAUSE_USERIDCAUSE=true HUDSON_SERVER_COOKIE=fdc4afdcedb676ccc4c91bd4629025ab SHELL=/bin/bash SSH_CLIENT=10.230.226.113 54164 22 BUILD_TAG=jenkins-test-100 SVN_REVISION_1=736113 SVN_REVISION_2=894518 WORKSPACE=/jenkins_slave/workspace/test SVN_REVISION_3=894501 JOB_URL=http://jenkins.xxx-inc.com:8080/job/test/ USER=root SVN_EDITOR=vim LD_LIBRARY_PATH=/usr/xxx/jdk1.6.0_18/jre/lib/amd64/server:/usr/xxx/jdk1.6.0_18/jre/lib/amd64:/usr/xxx/jdk1.6.0_18/jre/../lib/amd64:/lib64:/lib:/usr/lib64:/usr/lib:/usr/local/lib64/:/usr/local/lib:/usr/xxx/apache.ndx/modules:/root/jakarta-jmeter-2.3.4/lib/:/external/libesmtp-1.0.4-build/lib/esmtp-plugins/:/home/admin/mailserver/deplibs/lib64: NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JENKINS_HOME=/disk1/jenkins MAVEN_HOME=/usr/xxx/maven PATH=/home/admin/tools/jdk1.6.0_34/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin:/build/debug64/bin:/root/bin:/root/bob/bin:/usr/xxx/maven/bin:/usr/xxx/jdk/bin:/opt/ActivePython-2.7/bin MAIL=/var/mail/root _=/bin/env HOUYI_DEV_BRANCH_NAME=BugFix201211 SVN_OPT=--no-auth-cache --non-interactive --trust-server-cert PWD=/jenkins_slave/workspace/test JAVA_HOME=/home/admin/tools/jdk1.6.0_34 HUDSON_URL=http://jenkins.xxx-inc.com:8080/ LANG=en_US.UTF-8 JOB_NAME=test XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt BUILD_CAUSE=USERIDCAUSE BUILD_ID=2012-11-27_09-40-57 JENKINS_URL=http://jenkins.xxx-inc.com:8080/ HOME=/root SHLVL=2 JENKINS_SERVER_COOKIE=fdc4afdcedb676ccc4c91bd4629025ab EXECUTOR_NUMBER=0 NODE_LABELS=10.250.4.42 Mail_Test2 mailtest2 mailtest2_10.250.4.42 LOGNAME=root CVS_RSH=ssh SSH_CONNECTION=10.230.226.113 54164 10.250.4.42 22 HUDSON_HOME=/disk1/jenkins NODE_NAME=Mail_Test2 LESSOPEN=|/usr/bin/lesspipe.sh %s BUILD_NUMBER=100 HUDSON_COOKIE=bad8c43a-ad31-41cb-9f27-f5052a219a63 SVN_URL_1=http://svn.xxx.com/repos/mail/continue-integration/src/trunk SVN_URL_2=http://svn.xxx.com/repos/mail/continue-integration/scripts G_BROKEN_FILENAMES=1 SVN_URL_3=http://svn.xxx.com/repos/mail/java/webmail/branches/webmail2 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Bao Xiaopan(Bob) commented on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing @Oresztesz Margaritisz Pls upgrade your Jenkins to the latest version, I've tested your case on my Jenkins server with Jenkins ver. 1.491 and Subversion Plug-in ver. 1.43 , and it works perfectly. See my output, in my example, I set 3 svn url in the subversion plugin, and run "env" command in the shell step, it has a very clear output of 3 SVN_URL and 3 SVN_REVISION: [test] $ /bin/sh -xe /tmp/hudson4800466824911128402.sh + env BUILD_URL=http://jenkins.xxx-inc.com:8080/job/test/100/ BUILD_CAUSE_USERIDCAUSE=true HUDSON_SERVER_COOKIE=fdc4afdcedb676ccc4c91bd4629025ab SHELL=/bin/bash SSH_CLIENT=10.230.226.113 54164 22 BUILD_TAG=jenkins-test-100 SVN_REVISION_1=736113 SVN_REVISION_2=894518 WORKSPACE=/jenkins_slave/workspace/test SVN_REVISION_3=894501 JOB_URL=http://jenkins.xxx-inc.com:8080/job/test/ USER=root SVN_EDITOR=vim LD_LIBRARY_PATH=/usr/xxx/jdk1.6.0_18/jre/lib/amd64/server:/usr/xxx/jdk1.6.0_18/jre/lib/amd64:/usr/xxx/jdk1.6.0_18/jre/../lib/amd64:/lib64:/lib:/usr/lib64:/usr/lib:/usr/local/lib64/:/usr/local/lib:/usr/xxx/apache.ndx/modules:/root/jakarta-jmeter-2.3.4/lib/:/external/libesmtp-1.0.4-build/lib/esmtp-plugins/:/home/admin/mailserver/deplibs/lib64: NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JENKINS_HOME=/disk1/jenkins MAVEN_HOME=/usr/xxx/maven PATH=/home/admin/tools/jdk1.6.0_34/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin:/build/debug64/bin:/root/bin:/root/bob/bin:/usr/xxx/maven/bin:/usr/xxx/jdk/bin:/opt/ActivePython-2.7/bin MAIL=/var/mail/root _=/bin/env HOUYI_DEV_BRANCH_NAME=BugFix201211 SVN_OPT=--no-auth-cache --non-interactive --trust-server-cert PWD=/jenkins_slave/workspace/test JAVA_HOME=/home/admin/tools/jdk1.6.0_34 HUDSON_URL=http://jenkins.xxx-inc.com:8080/ LANG=en_US.UTF-8 JOB_NAME=test XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt BUILD_CAUSE=USERIDCAUSE BUILD_ID=2012-11-27_09-40-57 JENKINS_URL=http://jenkins.xxx-inc.com:8080/ HOME=/root SHLVL=2 JENKINS_SERVER_COOKIE=fdc4afdcedb676ccc4c91bd4629025ab EXECUTOR_NUMBER=0 NODE_LABELS=10.250.4.42 Mail_Test2 mailtest2 mailtest2_10.250.4.42 LOGNAME=root CVS_RSH=ssh SSH_CONNECTION=10.230.226.113 54164 10.250.4.42 22 HUDSON_HOME=/disk1/jenkins NODE_NAME=Mail_Test2 LESSOPEN=|/usr/bin/lesspipe.sh %s BUILD_NUMBER=100 HUDSON_COOKIE=bad8c43a-ad31-41cb-9f27-f5052a219a63 SVN_URL_1=http://svn.xxx.com/repos/mail/continue-integration/src/trunk SVN_URL_2=http://svn.xxx.com/repos/mail/continue-integration/scripts G_BROKEN_FILENAMES=1 SVN_URL_3=http://svn.xxx.com/repos/mail/java/webmail/branches/webmail2 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
abayer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Well, that's no good. Any chance you could (after making a copy of your config.xml) remove one of the jclouds clouds, see what happens, and then try adding it back? 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Rolling back core to 1.491 also has the same issue... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12827) api should return the build number that was queued.
TJ Biddle commented on JENKINS-12827 api should return the build number that was queued. +1. Was about to post this on GG. Hitting /build and /buildWithParameters really needs to return some type of data so we know the call was received and kicked off properly. To start: Build Number Parameters Time until it starts (If in queue) I'm making calls currently and I've had it silently fail a few times and I don't have any way to tell if this is happening and try again 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-11916) NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium
Aaron Briel updated JENKINS-11916 NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium Change By: Aaron Briel (26/Nov/12 11:42 PM) Attachment: regression_test_output.html 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-11916) NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium
Aaron Briel edited a comment on JENKINS-11916 NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium I'm running into this same issue when attempting to Publish Selenium Report with an HTMLTestRunner generated report. Tests are kicked off by Jenkins, all succeed, and the output file is generated to a directory in the Jenkins workspace that the user has permission to. I specified the full path to the directory and did not point to the HTML output file. ... Publishing Selenium report... Copying the reports. parsing resultFile regression_test_output.html Unable to parse regression_test_output.html: java.lang.NumberFormatException: null This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11916) NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium
Aaron Briel reopened JENKINS-11916 NullPointerException when trying to publish valid HTML reports generated by HTMLTestRunner 0.8.2/Selenium I'm running into this same issue. Tests are kicked off by Jenkins, all succeed, and the output file is generated to a directory in the Jenkins workspace that the user has permission to. ... Publishing Selenium report... Copying the reports. parsing resultFile regression_test_output.html Unable to parse regression_test_output.html: java.lang.NumberFormatException: null Change By: Aaron Briel (26/Nov/12 11:40 PM) Resolution: Not A Defect Status: Resolved Reopened 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer
updated JENKINS-15929
Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Change By:
Adam Rofer
(26/Nov/12 11:37 PM)
Description:
Booting up jenkins and using it works fine.If I visit the Configure System page, it appears to populate the settings I have correctly but then it freezes all of jenkins (first noticed as expanding a help bubble never succeeded). No more logs are produced by jenkins.Running jstack on the Jenkins process reveals this:
{noformat}
Found one Java-level deadlock:="Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread[#14]": waiting to lock Monitor@0x7f7ad800aac8 (Object@0x0004c4438d38, a java/lang/Class), which is held by "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread[#20]""Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread[#20]": waiting to lock Monitor@0x7f7afc207150 (Object@0x0004c1164bc8, a java/lang/Class), which is held by "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread[#14]"
{noformat}
Here are the thread stacktraces that contain RequestHandlerThread:{noformat}Thread 9255: (state = BLOCKED) - sun.reflect.annotation.AnnotationType.getInstance(java.lang.Class) @bci=0, line=63 (Interpreted frame) - sun.reflect.annotation.AnnotationParser.parseAnnotation(java.nio.ByteBuffer, sun.reflect.ConstantPool, java.lang.Class, boolean) @bci=94, line=202 (Interpreted frame) - sun.reflect.annotation.AnnotationParser.parseAnnotations2(byte[], sun.reflect.ConstantPool, java.lang.Class) @bci=39, line=69 (Compiled frame) - sun.reflect.annotation.AnnotationParser.parseAnnotations(byte[], sun.reflect.ConstantPool, java.lang.Class) @bci=11, line=52 (Compiled frame) - java.lang.Class.initAnnotationsIfNecessary() @bci=22, line=3070 (Interpreted frame) - java.lang.Class.getAnnotation(java.lang.Class) @bci=13, line=3029 (Interpreted frame) - com.google.inject.internal.Annotations.isRetainedAtRuntime(java.lang.Class) @bci=3, line=57 (Interpreted frame) - com.google.inject.Key.ensureRetainedAtRuntime(java.lang.Class) @bci=1, line=362 (Interpreted frame) - com.google.inject.Key.strategyFor(java.lang.annotation.Annotation) @bci=15, line=339 (Interpreted frame) - com.google.inject.Key.get(com.google.inject.TypeLiteral, java.lang.annotation.Annotation) @bci=6, line=274 (Interpreted frame) - com.google.inject.assistedinject.FactoryProvider2.assistKey(java.lang.reflect.Method, com.google.inject.Key, com.google.inject.internal.Errors) @bci=14, line=522 (Interpreted frame) - com.google.inject.assistedinject.FactoryProvider2.(com.google.inject.Key, com.google.inject.assistedinject.BindingCollector) @bci=306, line=235 (Interpreted frame) - com.google.inject.assistedinject.FactoryModuleBuilder$1.configure() @bci=15, line=334 (Interpreted frame) - com.google.inject.AbstractModule.configure(com.google.inject.Binder) @bci=31, line=62 (Interpreted frame) - com.google.inject.spi.Elements$RecordingBinder.install(com.google.inject.Module) @bci=31, line=229 (Interpreted frame) - com.google.inject.AbstractModule.install(com.google.inject.Module) @bci=5, line=121 (Interpreted frame) - org.jclouds.rest.config.RestModule.configure() @bci=36, line=96 (Interpreted frame) - org.jclouds.rest.config.RestClientModule.configure() @bci=1, line=77 (Interpreted frame) - org.jclouds.aws.ec2.config.AWSEC2RestClientModule.configure() @bci=33, line=164 (Interpreted frame) - com.google.inject.AbstractModule.configure(com.google.inject.Binder) @bci=31, line=62 (Interpreted frame) - com.google.inject.spi.Elements$RecordingBinder.install(com.google.inject.Module) @bci=31, line=229 (Interpreted frame) - com.google.inject.spi.Elements.getElements(com.google.inject.Stage, java.lang.Iterable) @bci=40, line=103 (Interpreted frame) - com.google.inject.internal.InjectorShell$Builder.build(com.google.inject.internal.Initializer, com.google.inject.internal.ProcessedBindingDa
[JIRA] (JENKINS-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath commented on JENKINS-15643 Consistent Out Of Memory Error When Adding 101st Build Node Good suggestion. We did have to bump up our max FD count a while back to get around another issue (too many open files), but the process limit is still set at default. Will give that a try. Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Note: This seemed to work quite recently, so it is possible that it is caused by upgrading to Jenkins 1.492 from 1.491 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
abayer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Could be - I know it's worked for me historically. I'll try to test this in 1.492 soon. 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer commented on JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Note: I have two JClouds profiles on the configure page. 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-15929) Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system
Adam Rofer created JENKINS-15929 Visiting Configure System page in Jenkins causes deadlock in JClouds plugin, freezing entire system Issue Type: Bug Assignee: abayer Components: jclouds Created: 26/Nov/12 11:23 PM Description: Booting up jenkins and using it works fine. If I visit the Configure System page, it appears to populate the settings I have correctly but then it freezes all of jenkins (first noticed as expanding a help bubble never succeeded). No more logs are produced by jenkins. Running jstack on the Jenkins process reveals this: Found one Java-level deadlock: = "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread14": waiting to lock Monitor@0x7f7ad800aac8 (Object@0x0004c4438d38, a java/lang/Class), which is held by "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread20" "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread20": waiting to lock Monitor@0x7f7afc207150 (Object@0x0004c1164bc8, a java/lang/Class), which is held by "Handling POST /jenkins/descriptorByName/jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate/fillHardwareIdItems : RequestHandlerThread14" I have the complete stack dump too, if that is needed. The only solution is restarting jenkins once the page has been visited. Environment: Jenkins 1.492, JClouds plugin 2.3.1, CentOS 6 Project: Jenkins Priority: Critical 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-15930) Getting "Status Code 404 :Page" on clicking the labels(with html script) of master node
venkatauday kumar created JENKINS-15930 Getting "Status Code 404 :Page" on clicking the labels(with html script) of master node Issue Type: Bug Affects Versions: current Assignee: domi Attachments: statuscode404#1.jpg, statuscode404#2.jpg, statuscode404#3.jpg, statuscode404#4.jpg, statuscode404#5.jpg Components: nodelabelparameter Created: 26/Nov/12 11:24 PM Description: Steps to follow: Step 1:Open the Jenkins web application.Default: "localhost:8080 Step 2:Click the hyperlink "Build Executor Status" Step 3:Click the tool image of the master or any other node. Step 4:A new html page will be opened. Step 5:In the label textbox, type the text(html code) as "google Step 6:Click on Save button. Step 7:User will be redirected to Master Jenkins node screen. Step 8:click on the label "href=""> Result : A page is displayed where it is showing the "Status Code: 404" For reference ,please find the attached screenshots Environment: Any platform Project: Jenkins Priority: Major Reporter: venkatauday kumar 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-15928) Add option to delete the emulator after build only if the build did not succeed
Uwe Kubosch created JENKINS-15928 Add option to delete the emulator after build only if the build did not succeed Issue Type: Improvement Affects Versions: current Assignee: Christopher Orr Components: android-emulator Created: 26/Nov/12 11:07 PM Project: Jenkins Priority: Major Reporter: Uwe Kubosch 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-15927) ivy-report-plugin: pull available information from Ivy files
Matt Benson created JENKINS-15927 ivy-report-plugin: pull available information from Ivy files Issue Type: Improvement Assignee: Unassigned Components: plugin Created: 26/Nov/12 10:26 PM Description: The Ivy plugin's configuration can be utilized to pull Ivy info including organisation/module name and configurations; therefore the "Resolve id" item is not necessary, and the "Ivy Configurations" item can be defaulted to "*" which Ivy can resolve to all configurations. To do these things sensibly, it is necessary to pull the Ivy info for all Ivy modules as well. Project: Jenkins Priority: Major Reporter: Matt Benson 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-15927) ivy-report-plugin: pull available information from Ivy files
Matt Benson assigned JENKINS-15927 to Matt Benson ivy-report-plugin: pull available information from Ivy files Change By: Matt Benson (26/Nov/12 10:26 PM) Assignee: Matt Benson 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-15845) java.lang.LinkageError on remote
olamy closed JENKINS-15845 as Duplicate java.lang.LinkageError on remote dupe of JENKINS-6604 Change By: olamy (26/Nov/12 10:05 PM) Status: Open Closed Assignee: olamy 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-12480) Build step that runs multiple jobs in parallel, and blocks until all are complete
Gardner Bickford commented on JENKINS-12480 Build step that runs multiple jobs in parallel, and blocks until all are complete Hi everyone. I registered this issue in the "kickstarting" section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/80/build-step-that-runs-multiple-jobs-in-parallel-and-blocks-until-all-are-complete and offer a few bucks for it. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15925) Changed delimiter of securityGroups from space to semi-colon.
Ken Garland commented on JENKINS-15925 Changed delimiter of securityGroups from space to semi-colon. Pull request has been made with modified code. https://github.com/jenkinsci/ec2-plugin/pull/28 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-15925) Changed delimiter of securityGroups from space to semi-colon.
Ken Garland started work on JENKINS-15925 Changed delimiter of securityGroups from space to semi-colon. Change By: Ken Garland (26/Nov/12 9:16 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12769) Cannot specify location of gradle wrapper
Gregory Boissinot resolved JENKINS-12769 as Fixed Cannot specify location of gradle wrapper Change By: Gregory Boissinot (26/Nov/12 9:11 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-15406) When using gradlew, root build script field is not used to locate gradlew
Gregory Boissinot resolved JENKINS-15406 as Fixed When using gradlew, root build script field is not used to locate gradlew Change By: Gregory Boissinot (26/Nov/12 9:12 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-15903) Broken URL for Monkey result icons
Christopher Orr closed JENKINS-15903 as Fixed Broken URL for Monkey result icons This was fixed in version 2.7 of the plugin, which has now been released. Change By: Christopher Orr (26/Nov/12 8:54 PM) 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-15903) Broken URL for Monkey result icons
SCM/JIRA link daemon commented on JENKINS-15903 Broken URL for Monkey result icons Code changed in jenkins User: Christopher Orr Path: src/main/resources/hudson/plugins/android_emulator/monkey/MonkeyAction/summary.jelly http://jenkins-ci.org/commit/android-emulator-plugin/5ba1168e54fa642729aa8cf328c904d94ea47ac5 Log: [FIXED JENKINS-15903] Remove now-redundant resURL from monkey summary jelly. Apparently Jenkins now inserts the 'static' URL itself, so this isn't needed. 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-15903) Broken URL for Monkey result icons
SCM/JIRA link daemon resolved JENKINS-15903 as Fixed Broken URL for Monkey result icons Change By: SCM/JIRA link daemon (26/Nov/12 8:27 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
h1. *assert classOwnership != null;// line 82*
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
{{
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
}}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
edited a comment on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu
commented on JENKINS-15782
InstantiationError when saving view configuration
impatience me... I decided to download the latest source from GIT to see if I can find the root cause of this issue... Here's what I found:
Based on the last exception stack:
Caused by: java.lang.AssertionError
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:82)
at hudson.util.RobustReflectionConverter.(RobustReflectionConverter.java:77)
at hudson.security.ProjectMatrixAuthorizationStrategy$ConverterImpl.(ProjectMatrixAuthorizationStrategy.java:103)
Line 103 of ProjectMatrixAuthorizationStrategy has the following:
public ConverterImpl(Mapper m) {
ref = new RobustReflectionConverter(m,new JVM().bestReflectionProvider()); // line 103
}
Line 77 of RobustReflectionConverter has the following:
public RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider) {
this(mapper, reflectionProvider, null);// line 77
}
Line 82 of RobustReflectionConverter has the following:
RobustReflectionConverter(Mapper mapper, ReflectionProvider reflectionProvider, XStream2.ClassOwnership classOwnership) {
this.mapper = mapper;
this.reflectionProvider = reflectionProvider;
assert classOwnership != null;// line 82
this.classOwnership = classOwnership;
serializationMethodInvoker = new SerializationMethodInvoker();
}
well... Jenkins calls the public construction of RobustReflectionConverter, which always pass null for 'classOwnership'. Hence it will ALWAYS be the case that we get this AssertionError.
Looks like a coding issue to me. Can someone please kindly and urgently fix this... This is causing a lot of problem for us.
Thank you very 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-15782) InstantiationError when saving view configuration
Mike Liu updated JENKINS-15782 InstantiationError when saving view configuration Change By: Mike Liu (26/Nov/12 8:05 PM) Priority: Major Critical Component/s: config-file-provider 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-15925) Changed delimiter of securityGroups from space to semi-colon.
Ken Garland updated JENKINS-15925 Changed delimiter of securityGroups from space to semi-colon. Change By: Ken Garland (26/Nov/12 7:49 PM) Summary: EC2 Security group with spaces in name Changed delimiter of securityGroups from space to semi-colon . Assignee: Francis Upton Ken Garland 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-15926) Build Failure Analyzer with Timestamper output ugly.
Larry Shatzer, Jr. updated JENKINS-15926 Build Failure Analyzer with Timestamper output ugly. Change By: Larry Shatzer, Jr. (26/Nov/12 7:19 PM) Component/s: timestamper 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-15926) Build Failure Analyzer with Timestamper output ugly.
Larry Shatzer, Jr. created JENKINS-15926 Build Failure Analyzer with Timestamper output ugly. Issue Type: Bug Assignee: Tomas Westling Components: build-failure-analyzer Created: 26/Nov/12 7:18 PM Description: When looking at a log that has the timestamper plugin enabled, I see something like this when I click on the line that trigger the build failure analyzer. [8mha:dB+LCABb85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgZGLwaB3MycnMzi4My85FTXgvzkjIoiBimoScn5ecX5Oal6zhAaVS9DRQGQtrZTnRAIAA6DkZ+B[0mmessage : Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project project-name: Compilation failure Project: Jenkins Priority: Major Reporter: Larry Shatzer, Jr. 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-15717) Failed to monitor warning
Mike Liu commented on JENKINS-15717 Failed to monitor warning same problem here... I was using v1.489 and just upgraded to v1.492. Issue still exists. 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-4960) Use same SCM checkout for all matrix entries
Kohsuke Kawaguchi resolved JENKINS-4960 as Fixed Use same SCM checkout for all matrix entries This was implemented as an SCMCheckoutStrategy extension point, but we still need someone to deliver the actual implementation of it. Change By: Kohsuke Kawaguchi (26/Nov/12 7:03 PM) Status: Open Resolved Assignee: Kohsuke Kawaguchi 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Oliver Walsh closed JENKINS-15919 as Fixed Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ Change By: Oliver Walsh (26/Nov/12 6:00 PM) 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Ulli Hafner commented on JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler Can you please check if that happens with the plain Java parser, too? Or why are you using the Eclipse Parser? Are there warnings not covered? 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Kohsuke Kawaguchi resolved JENKINS-15919 as Fixed Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ Fixed now. The addition of http://fallback.jenkins-ci.org/ caused this regression. Change By: Kohsuke Kawaguchi (26/Nov/12 5:47 PM) Status: Open Resolved Assignee: Kohsuke Kawaguchi 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-15487) External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put
Jesse Glick updated JENKINS-15487 External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put Change By: Jesse Glick (26/Nov/12 5:42 PM) Priority: Major Critical 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-15583) "building" builds (running builds) do not show up anymore in the list of builds of a job (json API)
Jesse Glick commented on JENKINS-15583 "building" builds (running builds) do not show up anymore in the list of builds of a job (json API) Seems to me that this is a regression: existing clients relying on builds should not have to be changed. getBuilds should once again be exported to the remote API as simply builds with default visibility, and newBuilds can be added as desired. 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-15925) EC2 Security group with spaces in name.
Ken Garland created JENKINS-15925 EC2 Security group with spaces in name. Issue Type: Task Affects Versions: current Assignee: Francis Upton Components: ec2 Created: 26/Nov/12 5:22 PM Description: When adding a security group that has a space in the name it is treated as multiple groups. Perhaps the delimiter should be changed to a comma or something else to keep spaces intact. Due Date: 26/Nov/12 12:00 AM Project: Jenkins Priority: Major Reporter: Ken Garland 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-15487) External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put
Greg horvath commented on JENKINS-15487 External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put Looks like we're getting lots of reports that this is not getting fixed in subsequent releases. Right now, a pretty important function is broken for us because of this. Is there any update on when we should expect a fix for this? Even an estimate would be useful (week, month, year, decade, etc). 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-15487) External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put
blalor commented on JENKINS-15487 External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put Still broken in 1.492. 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-15703) Cobertura ClassCastException
Rodolphe Quiédeville commented on JENKINS-15703 Cobertura ClassCastException I have the same symptom on Debain Wheezy with jenkins installed directly (not in tomcat) jenkins 1.447.2+dfsg-2 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Ryan Davis commented on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ I've installed jenkins via apt, per instructions on http://pkg.jenkins-ci.org/debian/, I get the similar 404 when trying to upgrade: $ sudo aptitude upgrade jenkins The following packages will be upgraded: jenkins 1 packages upgraded, 0 newly installed, 0 to remove and 26 not upgraded. Need to get 48.3 MB of archives. After unpacking 500 kB will be freed. Do you want to continue? [Y/n/?] Err http://pkg.jenkins-ci.org/debian/ binary/ jenkins 1.492 404 Not Found 0% [Working]E: Failed to fetch http://pkg.jenkins-ci.org/debian/binary/jenkins_1.492_all.deb: 404 Not Found E: Failed to fetch http://pkg.jenkins-ci.org/debian/binary/jenkins_1.492_all.deb: 404 Not Found 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-15924) Build Jobs formerly using Sidebar-Link Plugin vanished unintentionally
Oliver Merkel created JENKINS-15924 Build Jobs formerly using Sidebar-Link Plugin vanished unintentionally Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: sidebar-link Created: 26/Nov/12 4:05 PM Description: Reproduction: 1.) Install sidebar-link plugin 2.) Use sidebar link in a Build Job "foobar" Up to that point everything is fine. 3.) Now remove usage of sidebar plugin from the Build Job. Sidebar plugin is still installed! 4.) In config.xml of Build Job "foobar" there's still the empty XML element included now! 5.) If at any later time from now on Jenkins Job configuration is reloaded or Jenkins is restarted then the whole Build Job is gone (Not being displayed in your Browser any longer!). The correlated Build Job data still exists on the underlying mass storage device although it is not loaded. If in config.xml the line containing XML element is removed then after restart the Job is available again. Expected behaviour would be that such manual removal of this line shall not be neccessary. Thank you... Environment: Jenkins ver. 1.424.6 sidebar-link 1.6 Project: Jenkins Labels: plugin configuration Priority: Critical Reporter: Oliver Merkel 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Dmitry Tkachenko edited a comment on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ Same trouble with http://pkg.jenkins-ci.org/redhat/jenkins-1.492-1.1.noarch.rpm And when update Jenkins on Fedora - Jenkins failed when they try start. http://pkg.jenkins-ci.org/redhat/jenkins-1.491-1.1.noarch.rpm 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-15589) build URL in failed emails is broken
kutzi assigned JENKINS-15589 to Kohsuke Kawaguchi build URL in failed emails is broken Change By: kutzi (26/Nov/12 3:30 PM) Assignee: Kohsuke Kawaguchi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Dmitry Tkachenko commented on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ Same trouble with http://pkg.jenkins-ci.org/redhat/jenkins-1.492-1.1.noarch.rpm And when update Jenkins on Fedora - Jenkins filed when they try start. http://pkg.jenkins-ci.org/redhat/jenkins-1.491-1.1.noarch.rpm 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-15589) build URL in failed emails is broken
Jason Swager commented on JENKINS-15589 build URL in failed emails is broken We've noticed the same behavior: Jenkins v1.491 since upgrading from 1.484. We found another workaround - hit some page that list the jobs whose builds can't be accessed via direct URL. I suppose we could browse all jobs upon Jenkins startup to ensure this URL jumping behavior works correctly. But it would be much better if it just worked properly. 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Oresztesz Margaritisz edited a comment on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing Subversion plug-in should set this environment variables when job is executed. I think that it's not necessary to set them manually as environment variables. When we reverted back the subversion plug-in version to 1.37 it worked as expected. Following the job configuration I wrote, the output was similar to this: [workspace] $ /bin/sh -xe /tmp/hudson417259567168419629.sh + env JENKINS_HOME=/home/jenkins SVN_URL=svn://repo/projects/sample-project USER=jenkins MAIL=/var/mail/jenkins BUILD_CAUSE_USERIDCAUSE=true LD_LIBRARY_PATH=/usr/lib/j2re1.6-sun/lib/amd64/server:/usr/lib/j2re1.6-sun/lib/amd64:/usr/lib/j2re1.6-sun/../lib/amd64 HUDSON_URL=http://xxx/ NODE_LABELS=master SHLVL=1 HOME=/home/jenkins BUILD_URL=http://xxx:8080/job/bug-testing-job/1/ XDG_SESSION_COOKIE=1b7ec68ec015972008ea18b5502cfd37-1353159776.395303-1422605035 HUDSON_COOKIE=98bdb63c-c6ae-489b-aa47-418fbd331033 JENKINS_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 WORKSPACE=/home/jenkins/jobs/bug-testing-job/workspace NODE_NAME=master LOGNAME=jenkins _=/usr/bin/daemon BUILD_CAUSE=USERIDCAUSE EXECUTOR_NUMBER=1 OPENSSL_CONF=/etc/ssl/openssl.cnf TERM=linux HUDSON_HOME=/home/jenkins PATH=/usr/lib/jvm/jdk1.6.0_33/bin:/usr/local/bin:/usr/bin:/bin BUILD_ID=2012-11-26_15-54-38 BUILD_TAG=jenkins-bug-testing-job-1 LANG=en_US.UTF-8 JENKINS_URL=http://xxx:8080/ JOB_URL=http://xxx:8080/job/bug-testing-job/ BUILD_NUMBER=1 SHELL=/bin/bash XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt HUDSON_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 SVN_REVISION=19370 NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JOB_NAME=bug-testing-job PWD=/home/jenkins/jobs/bug-testing-job/workspace JAVA_HOME=/usr/lib/jvm/jdk1.6.0_33 Finished: SUCCESS Both SVN_URL and SVN_REVISION are set by 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Oresztesz Margaritisz edited a comment on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing Subversion plug-in should set this environment variables when job is executed. I think that it's not necessary to set them manually as environment variables. We reverted back the plug-in version to 1.37 it worked as expected. Following the configuration I wrote the output was similar to this: [workspace] $ /bin/sh -xe /tmp/hudson417259567168419629.sh + env JENKINS_HOME=/home/jenkins SVN_URL=svn://repo/projects/sample-project USER=jenkins MAIL=/var/mail/jenkins BUILD_CAUSE_USERIDCAUSE=true LD_LIBRARY_PATH=/usr/lib/j2re1.6-sun/lib/amd64/server:/usr/lib/j2re1.6-sun/lib/amd64:/usr/lib/j2re1.6-sun/../lib/amd64 HUDSON_URL=http://xxx/ NODE_LABELS=master SHLVL=1 HOME=/home/jenkins BUILD_URL=http://xxx:8080/job/bug-testing-job/1/ XDG_SESSION_COOKIE=1b7ec68ec015972008ea18b5502cfd37-1353159776.395303-1422605035 HUDSON_COOKIE=98bdb63c-c6ae-489b-aa47-418fbd331033 JENKINS_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 WORKSPACE=/home/jenkins/jobs/bug-testing-job/workspace NODE_NAME=master LOGNAME=jenkins _=/usr/bin/daemon BUILD_CAUSE=USERIDCAUSE EXECUTOR_NUMBER=1 OPENSSL_CONF=/etc/ssl/openssl.cnf TERM=linux HUDSON_HOME=/home/jenkins PATH=/usr/lib/jvm/jdk1.6.0_33/bin:/usr/local/bin:/usr/bin:/bin BUILD_ID=2012-11-26_15-54-38 BUILD_TAG=jenkins-bug-testing-job-1 LANG=en_US.UTF-8 JENKINS_URL=http://xxx:8080/ JOB_URL=http://xxx:8080/job/bug-testing-job/ BUILD_NUMBER=1 SHELL=/bin/bash XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt HUDSON_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 SVN_REVISION=19370 NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JOB_NAME=bug-testing-job PWD=/home/jenkins/jobs/bug-testing-job/workspace JAVA_HOME=/usr/lib/jvm/jdk1.6.0_33 Finished: SUCCESS Both SVN_URL and SVN_REVISION are set by 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Oresztesz Margaritisz edited a comment on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing Subversion plug-in should set this environment variables when job is executed. I think that it's not necessary to set them manually as environment variables. We reverted back the plug-in version to 1.37 it worked as expected. Following the configuration I wrote the output was similar to this: [workspace] $ /bin/sh -xe /tmp/hudson417259567168419629.sh + env JENKINS_HOME=/home/jenkins SVN_URL=svn://repo/projects/sample-project USER=jenkins MAIL=/var/mail/jenkins BUILD_CAUSE_USERIDCAUSE=true LD_LIBRARY_PATH=/usr/lib/j2re1.6-sun/lib/amd64/server:/usr/lib/j2re1.6-sun/lib/amd64:/usr/lib/j2re1.6-sun/../lib/amd64 HUDSON_URL=http://xxx/ NODE_LABELS=master SHLVL=1 HOME=/home/jenkins BUILD_URL=http://xxx:8080/job/bug-testing-job/1/ XDG_SESSION_COOKIE=1b7ec68ec015972008ea18b5502cfd37-1353159776.395303-1422605035 HUDSON_COOKIE=98bdb63c-c6ae-489b-aa47-418fbd331033 JENKINS_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 WORKSPACE=/home/jenkins/jobs/bug-testing-job/workspace NODE_NAME=master LOGNAME=jenkins _=/usr/bin/daemon BUILD_CAUSE=USERIDCAUSE EXECUTOR_NUMBER=1 OPENSSL_CONF=/etc/ssl/openssl.cnf TERM=linux HUDSON_HOME=/home/jenkins PATH=/usr/lib/jvm/jdk1.6.0_33/bin:/usr/local/bin:/usr/bin:/bin BUILD_ID=2012-11-26_15-54-38 BUILD_TAG=jenkins-bug-testing-job-1 LANG=en_US.UTF-8 JENKINS_URL=http://xxx:8080/ JOB_URL=http://xxx:8080/job/bug-testing-job/ BUILD_NUMBER=1 SHELL=/bin/bash XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt HUDSON_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 SVN_REVISION=19370 NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JOB_NAME=bug-testing-job PWD=/home/jenkins/jobs/bug-testing-job/workspace JAVA_HOME=/usr/lib/jvm/jdk1.6.0_33 Finished: SUCCESS Both SVN_URL and SVN_REVISION are set by 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Oresztesz Margaritisz commented on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing Subversion plug-in should set this environment variables when job is executed. We reverted back the plug-in version to 1.37 it worked as expected. Following the configuration I wrote the output was similar to this: [workspace] $ /bin/sh -xe /tmp/hudson417259567168419629.sh + env JENKINS_HOME=/home/jenkins SVN_URL=svn://repo/projects/sample-project USER=jenkins MAIL=/var/mail/jenkins BUILD_CAUSE_USERIDCAUSE=true LD_LIBRARY_PATH=/usr/lib/j2re1.6-sun/lib/amd64/server:/usr/lib/j2re1.6-sun/lib/amd64:/usr/lib/j2re1.6-sun/../lib/amd64 HUDSON_URL=http://xxx/ NODE_LABELS=master SHLVL=1 HOME=/home/jenkins BUILD_URL=http://xxx:8080/job/bug-testing-job/1/ XDG_SESSION_COOKIE=1b7ec68ec015972008ea18b5502cfd37-1353159776.395303-1422605035 HUDSON_COOKIE=98bdb63c-c6ae-489b-aa47-418fbd331033 JENKINS_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 WORKSPACE=/home/jenkins/jobs/bug-testing-job/workspace NODE_NAME=master LOGNAME=jenkins _=/usr/bin/daemon BUILD_CAUSE=USERIDCAUSE EXECUTOR_NUMBER=1 OPENSSL_CONF=/etc/ssl/openssl.cnf TERM=linux HUDSON_HOME=/home/jenkins PATH=/usr/lib/jvm/jdk1.6.0_33/bin:/usr/local/bin:/usr/bin:/bin BUILD_ID=2012-11-26_15-54-38 BUILD_TAG=jenkins-bug-testing-job-1 LANG=en_US.UTF-8 JENKINS_URL=http://xxx:8080/ JOB_URL=http://xxx:8080/job/bug-testing-job/ BUILD_NUMBER=1 SHELL=/bin/bash XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt HUDSON_SERVER_COOKIE=82cbdf46918417a5e048637649ff7175 SVN_REVISION=19370 NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat JOB_NAME=bug-testing-job PWD=/home/jenkins/jobs/bug-testing-job/workspace JAVA_HOME=/usr/lib/jvm/jdk1.6.0_33 Finished: SUCCESS 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-15923) embunit support
Joakim Plate created JENKINS-15923 embunit support Issue Type: Improvement Assignee: Gregory Boissinot Attachments: embunit-to-junit.xsl Components: xunit Created: 26/Nov/12 2:53 PM Description: Here is a xsl file for initial support of embunit xml output. Also note that the usage of putting xsl's in dirs like: /var/lib/jenkins/userContent/xunit/embUnit/1.0.0/ As mentioned in docs seem non working. I never was able to get it to show up in selection box, nor able to put some relative path in the custom xsl dialog box. On older xunit's full paths seemed to work fine, but on current it seemed to require the xsl to be in the working directory. Project: Jenkins Priority: Minor Reporter: Joakim Plate 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-14475) Conditional build steps should be available as post-build actions
emszpak commented on JENKINS-14475 Conditional build steps should be available as post-build actions owenmehegan: where you able to successfully chain plugins (Flexible Publish -> Conditional Build Step -> Parameterized Trigger)? I was not able to choose "Conditional Build Step" as an action for "Flexible Publish". Maybe you were able to workaround it in some other way? 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Stéphane Nicoll commented on JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler 350kb. After 1h15, it is still on at hudson.plugins.warnings.parser.RegexpParser.findAnnotations(RegexpParser.java:86) Seems a lot for ~4000 lines 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-12769) Cannot specify location of gradle wrapper
merscwog commented on JENKINS-12769 Cannot specify location of gradle wrapper This is a current blocker for attempting to utilize this gradle plugin and the gradle wrapper together for several valid use cases. There were two highly generalized solutions that are in pull requests from about 3 months ago (there might be some reason why they were not incorporated, as I've not tested either). I submitted a limited solution just over a week ago as a pull request that simply allows gradlew to selectively be found in the same directory as the root build file or workspace top, which required very minor modifications to the existing code base. 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-15501) Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2)
Bao Xiaopan(Bob) stopped work on JENKINS-15501 Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2) Change By: Bao Xiaopan(Bob) (26/Nov/12 2:16 PM) Status: In Progress Open This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15501) Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2)
Bao Xiaopan(Bob) started work on JENKINS-15501 Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2) Change By: Bao Xiaopan(Bob) (26/Nov/12 2:15 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15501) Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2)
Bao Xiaopan(Bob) updated JENKINS-15501 Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2) Change By: Bao Xiaopan(Bob) (26/Nov/12 2:10 PM) Labels: Validating-String-Parameter jenkins plugin rebuild 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-15501) Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2)
Bao Xiaopan(Bob) edited a comment on JENKINS-15501 Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2) @cjo9900 U r right, yes, we should have the regex stored in the parameters when using validating parameters. And for the solution, is it possible to release an official patch/update for the rebuild plugin? Coz for most of us, we don't have enough knowledge about java, Anyway, I will re-assign the issue first... 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-15501) Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2)
Bao Xiaopan(Bob) commented on JENKINS-15501 Can't do "Rebuild" Action if Use the Validating String Parameter Plugin(2.2) @cjo9900 U r right, yes, we should have the regex stored in the parameters when using validating parameters. And for the solution, is it possible to release an official patch/update for the rebuild plugin? Coz for most of us, we don't have enough knowledge about 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-14797) SVN_URL and SVN_REVISION environment variables are missing
Bao Xiaopan(Bob) commented on JENKINS-14797 SVN_URL and SVN_REVISION environment variables are missing It's possible, if you didn't set the "SVN_URL" as an env variable. So, pls first make sure about that you have already set the "SVN_URL" as an env variable. 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Ulli Hafner commented on JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler Ok, thanks, seems that the problem is unrelated to JENKINS-10097. The process "hangs" while scanning for warnings using a regular _expression_ matcher. How large is your console log? The eclipse parsers is a slow multi-line parser that reads the whole console log into a buffer. Would it be possible to pipe the warnings to an additional file? BTW: I think you do not need to activate the Eclipse parser, since the warnings seems to be in the default javac format (due to the maven 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-15922) Parallel block is executed ignoring a failed previous job
Ulf Bamberg commented on JENKINS-15922 Parallel block is executed ignoring a failed previous job For all users having the same issue, i got a temporary workaround. All parallel blocks have to be outsourced to seperate build-flow jobs causing the parallel exection to be skipped. 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-15922) Parallel block is executed ignoring a failed previous job
Ulf Bamberg
created JENKINS-15922
Parallel block is executed ignoring a failed previous job
Issue Type:
Bug
Affects Versions:
current
Assignee:
Nicolas De Loof
Attachments:
parallelBuildFlow.txt
Components:
build-flow
Created:
26/Nov/12 1:47 PM
Description:
Jobs in parallel blocks are executed, although a previous job in the pipeline failed. Following sequential executed jobs are skipped as expected.
See the attached definition. build("flow.fail") fails -> builds of flow.ok1-3 are executed -> flow.ok4 is skipped as expected.
Im expecting the parallel block either to be skipped.
Environment:
buildflow 0.6
jenkins 1.491
Project:
Jenkins
Priority:
Major
Reporter:
Ulf Bamberg
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-15900) A build failure in a parallel section does not mark it as failed
Rob Sweet commented on JENKINS-15900 A build failure in a parallel section does not mark it as failed It's great to have a work-around but I had the same scenario when trying to set up a build pipeline for my project and was definitely surprised to have the second phase of tests run when the previous phase had failed. It really seems like the behavior for multiple parallel statements should follow the behavior for build statements and not run the next one if something in the current parallel() block fails. Thanks for building this great 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-15829) hg share always recreating working copy on slave (on master it's working fine)
Igor Kostenko commented on JENKINS-15829 hg share always recreating working copy on slave (on master it's working fine) If somebody else have the same issue, here the workaround which I'm using on slaves: In Source Code Management / Mercurial / Advanced / Subdirectory I'm specifying directory fake and adding at the beginning of build Unix: if [ -d MyRepo ]; then hg -R MyRepo update else hg --config extensions.share= share fake MyRepo fi Windows: if exist MyRepo\nul (hg -R MyRepo update) else (hg --config extensions.share= share fake MyRepo) 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-15921) 1.492 Jenkins Debian packages not found
bitard michael created JENKINS-15921 1.492 Jenkins Debian packages not found Issue Type: Bug Assignee: Unassigned Components: update-center Created: 26/Nov/12 1:31 PM Description: The url http://pkg.jenkins-ci.org/debian/binary/jenkins_1.492_all.deb redirect to http://fallback.jenkins-ci.org/debian/jenkins_1.492_all.deb which is not found. Same issue: JENKINS-15435 Environment: OS : Ubuntu 12.04 Project: Jenkins Priority: Major Reporter: bitard michael 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Stéphane Nicoll commented on JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler Sorry it took so long to get those info. Let me know if you need anything else. 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Stéphane Nicoll updated JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler thread dump Change By: Stéphane Nicoll (26/Nov/12 1:20 PM) Attachment: thread-dump.txt Attachment: thread-dump-2.txt 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-15895) Job stuck collecting compiler warnings with the eclipse compiler
Stéphane Nicoll commented on JENKINS-15895 Job stuck collecting compiler warnings with the eclipse compiler [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ com.bsb.fluid.core.ui-incubator --- [INFO] Compiling (JDT) 26 source files to C:\stuff\ci\jenkins\jobs\incubator-fluid\workspace\core\com.bsb.fluid.core.ui-incubator\target\test-classes [WARNING] C:\stuff\ci\jenkins\jobs\incubator-fluid\workspace\core\com.bsb.fluid.core.ui-incubator\target\generated-sources\test-annotations\com\bsb\fluid\test\core\ui\task\MDummyPersonCrudTaskController.java:[34,0] Type safety: Unchecked invocation cast(PathFactory) of the generic method cast(PathFactory) of type BasePath [WARNING] C:\stuff\ci\jenkins\jobs\incubator-fluid\workspace\core\com.bsb.fluid.core.ui-incubator\target\generated-sources\test-annotations\com\bsb\fluid\test\core\ui\task\MDummyPersonCrudTaskController.java:[34,0] Type safety: The _expression_ of type MDefaultCrudTaskController needs unchecked conversion to conform to MDefaultCrudTaskController> [WARNING] C:\stuff\ci\jenkins\jobs\incubator-fluid\workspace\core\com.bsb.fluid.core.ui-incubator\target\generated-sources\test-annotations\com\bsb\fluid\test\core\ui\task\MDummyPersonCrudTaskController.java:[34,0] Type safety: Unchecked invocation type(Class, Class) of the generic method type(Class, Class) of type MDefaultCrudTaskController [WARNING] C:\stuff\ci\jenkins\jobs\incubator-fluid\workspace\core\com.bsb.fluid.core.ui-incubator\target\generated-sources\test-annotations\com\bsb\fluid\test\core\ui\task\MDummyPersonCrudTaskController.java:[34,0] Type safety: The _expression_ of type PathFactory needs unchecked conversion to conform to PathFactory>> mojoSucceeded org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-testCompile) mojoStarted org.apache.maven.plugins:maven-surefire-plugin:2.12(default-test) [INFO] 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-15813) TAP files considered as binary files are ignored
Bruno P. Kinoshita commented on JENKINS-15813 TAP files considered as binary files are ignored Thanks a ton Michael! I've also updated the Wiki. The other limitation had already been implemented in a past version. Will close this issue once the next version is released (scheduled to this next Saturday). Thanks again! Bruno 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Herbert Vojčík commented on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ Same for http://pkg.jenkins-ci.org/redhat/. 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Oliver Walsh commented on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ How about rsync with --delay-updates? 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-15094) Multijob with use of parameter from type “File Parameter” all Executors are becoming Dead (!)
Doron Shai commented on JENKINS-15094 Multijob with use of parameter from type “File Parameter” all Executors are becoming Dead (!) This issue is a real pain since when using the MultiJob Plugin there is no real way to use the Parametrized Build Plugin and therefore passing parameters from MultiJob Phase to another MultiJob Phase is not possible. 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-15919) Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/
Michael Prokop commented on JENKINS-15919 Broken link for 1.492 on http://pkg.jenkins-ci.org/debian/ This issue happened several times throughout the last few months. The mirrors shouldn't announce Debian packages which aren't present yet. Related: http://rgeissert.blogspot.co.at/2012/10/rsync-is-not-enough.html HTH && regards, Michael 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-15322) NOTESTS in TAP response gives parse error and stack trace from plugin
Bruno P. Kinoshita commented on JENKINS-15322 NOTESTS in TAP response gives parse error and stack trace from plugin > Perhaps there's a mismatch here somewhere between the TAP produced by our Test::More module and Tap::Harness and the TAP specifications. Or maybe the plugin is expecting a different TAP version? Probably. The plug-in is expecting TAP 13, thought TAP 12 syntax was more similar to TAP 13, but never worked with this version. > Currently I can't investigate further as http://testanything.org is down at the moment. The site has been down for over a week. I'll drop an e-mail to the mailing list and hopefully someone will fix it. >In our projects we can't easily switch to using prove from the command line or a bash script as our .t files aren't static, they rely on a whole bunch of variable being passed into them via the TAP::Harness, there may be other workarounds possible though. Sounds like an interesting case. I don't have Perl in this computer (got a new one) but I will try something from this blog post [1]. In case you have some spare time to take a look on this and see if anything makes sense... my Perl skills are quite limited [1] http://www.effectiveperlprogramming.com/blog/1271 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-15813) TAP files considered as binary files are ignored
Michael Prokop commented on JENKINS-15813 TAP files considered as binary files are ignored Hi Bruno, thanks for your answer. I just added the according information at https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin (see 2nd bullet under "Known Limitations"). Feel free to close this issue. thanks for your work on the TAP plugin, regards, Michael 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-15218) Dependency tree should be constrained to only contain relevant nodes in the path
David Ehrenberger commented on JENKINS-15218 Dependency tree should be constrained to only contain relevant nodes in the path In my organization we have a very wide dependency trees where numerous projects utilize our core library package (i.e., Test.Job.1). When inside the job page of a particular project (i.e., Test.Job.3), I don't care about all of the other jobs (i.e., Test.Job.4) that also happen to utilize Test.Job.1. In my mind, I think it more intuitive that only those jobs that are actually dependencies are shown. Could this be made configurable? 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-15682) archive artifacts hangs on ia64 slave
Natalia Naumova commented on JENKINS-15682 archive artifacts hangs on ia64 slave Looks like the problem occurs with connection to the slave. The archive artifacts hang because the connection between slave and master is terminated soon after slave restart: = Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows. java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native at org.jruby.ext.posix.POSIXFactory.loadLibC(POSIXFactory.java:96) at org.jruby.ext.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:65) at org.jruby.ext.posix.POSIXFactory.getPOSIX(POSIXFactory.java:24) at hudson.os.PosixAPI.(PosixAPI.java:41) at hudson.Util.resolveSymlink(Util.java:1074) at hudson.util.DirScanner$Glob.scan(DirScanner.java:121) at hudson.FilePath.writeToTar(FilePath.java:1827) at hudson.FilePath.access$1000(FilePath.java:166) at hudson.FilePath$36.invoke(FilePath.java:1768) at hudson.FilePath$36.invoke(FilePath.java:1765) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2236) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Nov 26, 2012 4:20:28 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.io.StreamCorruptedException: invalid type code: 3B at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) 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) channel stopped ERROR: Connection terminated == 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-15712) The Locale dropdown is having a spelling mistake "Telgu"
SCM/JIRA link daemon commented on JENKINS-15712 The Locale dropdown is having a spelling mistake "Telgu" Code changed in jenkins User: Seiji Sogabe Path: src/main/java/hudson/plugins/translation/Locales.java http://jenkins-ci.org/commit/translation-plugin/680ab6cbce98c4887565acc8088f31809aef7dbd Log: [FIXED JENKINS-15712] The Locale dropdown is having a spelling mistake "Telgu" 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-15712) The Locale dropdown is having a spelling mistake "Telgu"
SCM/JIRA link daemon resolved JENKINS-15712 as Fixed The Locale dropdown is having a spelling mistake "Telgu" Change By: SCM/JIRA link daemon (26/Nov/12 12:21 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-15712) The Locale dropdown is having a spelling mistake "Telgu"
SCM/JIRA link daemon commented on JENKINS-15712 The Locale dropdown is having a spelling mistake "Telgu" Code changed in jenkins User: Seiji Sogabe Path: src/main/java/hudson/plugins/translation/Locales.java http://jenkins-ci.org/commit/translation-plugin/7dd375946c3710b6a7d7c2a9ebfe50962beb67e7 Log: Merge pull request #2 from ssogabe/JENKINS-15712 [FIXED JENKINS-15712] The Locale dropdown is having a spelling mistake "... Compare: https://github.com/jenkinsci/translation-plugin/compare/f1458a7e2c9e...7dd375946c37 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-15918) RunParameter environment variabes contain . character
Geoff Cummings
updated JENKINS-15918
RunParameter environment variabes contain . character
Change By:
Geoff Cummings
(26/Nov/12 12:17 PM)
Description:
The RunParameter creates 2 environment variables which contain a '.' character.I cannot reference these environment variables from a bash script due to this character.env
PARAMETER_NAME
PARAMETER_X
=http://xxx/jenkins/job/ASE_CI/2072/
PARAMETER_NAME
PARAMETER_X
.number=2072
PARAMETER_NAME
PARAMETER_X
.jobName=ASE_CIecho ${PARAMETER_NAME.number}${PARAMETER_NAME.number}: bad substitution Can you also create environment variables which use an underscore?
PARAMETER_NAME
PARAMETER_X
PARAMETER_NAME_NUMBER
PARAMETER_X_NUMBER
PARAMETER_NAME_NAME
PARAMETER_X_JOBNAME
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-15920) Boolean parameter becomes string
Alex Vesely updated JENKINS-15920 Boolean parameter becomes string Change By: Alex Vesely (26/Nov/12 11:54 AM) Affects Version/s: current 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-15682) archive artifacts hangs on ia64 slave
Sergey Smirnov updated JENKINS-15682 archive artifacts hangs on ia64 slave Change By: Sergey Smirnov (26/Nov/12 11:50 AM) Priority: Major Blocker 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-15920) Boolean parameter becomes string
Alex Vesely created JENKINS-15920 Boolean parameter becomes string Issue Type: Bug Assignee: huybrechts Attachments: _bad.png, _good.png Components: parameterized-trigger Created: 26/Nov/12 11:48 AM Description: I have a boolean parameter in my job. It is shown as a checkbox on the job 'parameters' page. When I trigger this job via the Parameterized Trigger plug-in, I set the parameter the following way: NIGHTLY=true As a result, the triggered job has the word "true", not the checkbox. See screenshots attached. Project: Jenkins Priority: Minor Reporter: Alex Vesely 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-15322) NOTESTS in TAP response gives parse error and stack trace from plugin
Alex Newnham reopened JENKINS-15322 NOTESTS in TAP response gives parse error and stack trace from plugin Reopening. Change By: Alex Newnham (26/Nov/12 11:17 AM) Resolution: Not A Defect Status: Resolved Reopened 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
