[JIRA] (JENKINS-13614) archiving artefacts from remote MacOS X, IBM AIX slave fails
WH commented on JENKINS-13614 archiving artefacts from remote MacOS X, IBM AIX slave fails With 1.486 I have no problems anymore. The exception "UnsupportedOperationException" is gone. Master: Windows XP, JDK6 (Oracle) Slave1: AIX 5.3, Java6 64-bit SDK (IBM) Slave2: AIX 6.1, Java6 64-bit SDK (IBM) I'm still waiting for the next LTS release which includes the fixes. BTW: Now I have a problem with the Copy Artifact Plugin, which sometimes doesn't copy artifacts of some configuration builds of a matrix job. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15634) Ignore aborted builds in age calculation for failing tests
Kamil Janyga created JENKINS-15634 Ignore aborted builds in age calculation for failing tests Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: junit Created: 26/Oct/12 7:02 AM Description: When test fails in one build, then the second build is aborted - in the third one the age of a testcase failure will be 1 instead of 3 (example test could not be executed). In big projects with thousands of tests it is hard to determine the reason of failure in such situations as above. All the test results history is corrupted. Maybe It is a good idea to ignore aborted builds in age calculation. Due Date: 26/Oct/12 12:00 AM Project: Jenkins Labels: junit testing reporting Priority: Major Reporter: Kamil Janyga This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15356) NPE caused executor thread death
Cees Bos commented on JENKINS-15356 NPE caused executor thread death This is a blocker for use. We upgraded to 1.487 and now all we see on serveral machines (with 1 executor) the Thread death with this stacktrace. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15356) NPE caused executor thread death
Cees Bos updated JENKINS-15356 NPE caused executor thread death Change By: Cees Bos (26/Oct/12 7:05 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-15356) NPE caused executor thread death
Cees Bos updated JENKINS-15356 NPE caused executor thread death Change By: Cees Bos (26/Oct/12 7:20 AM) Component/s: matrix This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15634) Ignore aborted builds in age calculation for failing tests
Kamil Janyga assigned JENKINS-15634 to Kamil Janyga Ignore aborted builds in age calculation for failing tests Change By: Kamil Janyga (26/Oct/12 8:02 AM) Assignee: KamilJanyga This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15634) Ignore aborted builds in age calculation for failing tests
Kamil Janyga started work on JENKINS-15634 Ignore aborted builds in age calculation for failing tests Change By: Kamil Janyga (26/Oct/12 8:10 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15626) java.lang.IllegalArgumentException: CloverPublisher is ambiguous; matches both org.jenkinsci.plugins.cloverphp.CloverPublisher and hudson.plugins.clover.CloverPublisher
Tarjei Huse updated JENKINS-15626 java.lang.IllegalArgumentException: CloverPublisher is ambiguous; matches both org.jenkinsci.plugins.cloverphp.CloverPublisher and hudson.plugins.clover.CloverPublisher I think this is a CloverPhp vs Clover conflict. Change By: Tarjei Huse (26/Oct/12 8:14 AM) Description: StatusCode:500Exception:java.lang.IllegalArgumentException:CloverPublisherisambiguous;matchesbothorg.jenkinsci.plugins.cloverphp.CloverPublisherandhudson.plugins.clover.CloverPublisherStacktrace:javax.servlet.ServletException:java.lang.IllegalArgumentException:CloverPublisherisambiguous;matchesbothorg.jenkinsci.plugins.cloverphp.CloverPublisherandhudson.plugins.clover.CloverPublisher atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:616) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659) atorg.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:488) atorg.kohsuke.stapler.Stapler.service(Stapler.java:162) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:45) atwinstone.ServletConfiguration.execute(ServletConfiguration.java:248) atwinstone.RequestDispatcher.forward(RequestDispatcher.java:333) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) athudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) athudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) athudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atjenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) athudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) athudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) athudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) atorg.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) athudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194)
[JIRA] (JENKINS-14675) Schema 'DBUSER' does not exist error in integrity plugin
Jérémie Bousquet commented on JENKINS-14675 Schema DBUSER does not exist error in integrity plugin Hi, I have that same problem and it seems it appeared after migration from old version of plugin. But I don't want to delete all prior builds, because I want to keep that history. Isn't there any other workaround ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15635) NPE on jenkins home after upgrade from 1.486 to 1.487
Tobias W. created JENKINS-15635 NPE on jenkins home after upgrade from 1.486 to 1.487 Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: Bildschirmfoto 2012-10-26 um 10.43.09.png Components: core Created: 26/Oct/12 8:45 AM Description: After upgrading from 1.486 to 1.487 jenkins only provides the following NPE. java.lang.NullPointerException at org.jenkinsci.main.modules.instance_identity.InstanceIdentity.getPublic(InstanceIdentity.java:81) at org.jenkinsci.modules.launchd_slave_installer.ComputerListenerImpl.onOnline(ComputerListenerImpl.java:27) at jenkins.model.Jenkins.init(Jenkins.java:840) at hudson.model.Hudson.init(Hudson.java:81) at hudson.model.Hudson.init(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:214) the log of the slaves says : [10/26/12 10:19:15] [SSH] Opening SSH connection to simons-mac-mini.intern:22. [10/26/12 10:19:15] [SSH] Authenticating as jenkins with /var/lib/jenkins/.ssh/id_rsa. [10/26/12 10:19:15] [SSH] Authentication successful. [10/26/12 10:19:15] [SSH] The remote users environment is: BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="2" [2]="48" [3]="1" [4]="release" [5]="x86_64-apple-darwin11") BASH_VERSION='3.2.48(1)-release' DIRSTACK=() EUID=235 GROUPS=() HOME=/Users/Shared/Jenkins HOSTNAME=simons-mac-mini.intern HOSTTYPE=x86_64 IFS=$' \t\n' LOGNAME=jenkins MACHTYPE=x86_64-apple-darwin11 MAIL=/var/mail/jenkins OPTERR=1 OPTIND=1 OSTYPE=darwin11 PATH=/usr/bin:/bin:/usr/sbin:/sbin PPID=88642 PS4='+ ' PWD=/Users/Shared/Jenkins SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 SSH_CLIENT='192.168.0.18 39804 22' SSH_CONNECTION='192.168.0.18 39804 192.168.0.155 22' TERM=dumb TMPDIR=/var/folders/ln/lm4r8z013vb0lm8bqyvl12y07b/T/ UID=235 USER=jenkins _=bash [10/26/12 10:19:15] [SSH] Checking java version of java [10/26/12 10:19:15] [SSH] java -version returned 1.6.0_35. [10/26/12 10:19:15] [SSH] Starting sftp client. [10/26/12 10:19:15] [SSH] Copying latest slave.jar... [10/26/12 10:19:16] [SSH] Copied 278.201 bytes. [10/26/12 10:19:16] [SSH] Starting slave process: cd 'dev/jenkins' java -jar slave.jar ===[JENKINS REMOTING CAPACITY]===channel started Slave.jar version: 2.17 Dies ist ein UNIX-Slave Copied maven-agent.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied classworlds.jar Evacuated stdout ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins. ha:WB+LCABb85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWA=java.lang.NullPointerException at org.jenkinsci.main.modules.instance_identity.InstanceIdentity.getPublic(InstanceIdentity.java:81) at org.jenkinsci.modules.launchd_slave_installer.ComputerListenerImpl.onOnline(ComputerListenerImpl.java:27) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:396) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:317) at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:454) at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:293) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) [10/26/12 10:19:18] [SSH] Connection closed. ERROR: Connection terminated ha:WB+LCABb85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWA=java.io.IOException: Unexpected termination of the channel at
[JIRA] (JENKINS-15570) Coverage report includes classes that have been excluded from Jacoco analysis
Ognjen Bubalo commented on JENKINS-15570 Coverage report includes classes that have been excluded from Jacoco analysis Hi, Please give us more information. Which plugin version do you use? What is your current configuration on the configuration page of JaCoCo plugin? Cheers, Ogi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12735) No upstream or downstream resolution with Maven version ranges
Michael Glauche commented on JENKINS-12735 No upstream or downstream resolution with Maven version ranges I'm having the same problem as Jay, this change makes this option useless, as we would end up having nearly every project depended on other project. Please re-open 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-12735) No upstream or downstream resolution with Maven version ranges
Michael Glauche reopened JENKINS-12735 No upstream or downstream resolution with Maven version ranges Please look on this again, the latest change create huge list of downstream projects to build. (although they are not really affected) Change By: Michael Glauche (26/Oct/12 9:11 AM) Resolution: Fixed 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-5207) DownstreamBuildViewPublisher fails to resolve class and also generates huge quantities of log entries in catalina log file
Erik Riemers commented on JENKINS-5207 DownstreamBuildViewPublisher fails to resolve class and also generates huge quantities of log entries in catalina log file If you have strange $ signs in one of your dirs it might not work. find . -name build.xml | xargs -I %f% perl -i -p -e 'undef $/; s/\s*org.jvnet.hudson.plugins.DownstreamBuildViewAction.*\/org.jvnet.hudson.plugins.DownstreamBuildViewAction//s' '%f%' Seems to work better for that. (still ugly) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14675) Schema 'DBUSER' does not exist error in integrity plugin
Jérémie Bousquet commented on JENKINS-14675 Schema DBUSER does not exist error in integrity plugin Forget my comment, re-launching the job solved the 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-15523) cppcheck: WARNING: Failed to resolve class
Wolfgang Hauser commented on JENKINS-15523 cppcheck: WARNING: Failed to resolve class My previous version of plugin was 1.9. Cppcheck 1.53 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15636) Wall Display plugin unusable in Internet Explorer 8 and 10
Christian Tellefsen created JENKINS-15636 Wall Display plugin unusable in Internet Explorer 8 and 10 Issue Type: Bug Affects Versions: current Assignee: Christian Pelster Attachments: walldisplay-ie8.png Components: walldisplay Created: 26/Oct/12 12:49 PM Description: When using Internet Explorer 8 and 10 the green/red/grey backgrounds are resized correctly, but the overall page is about 30% too wide, and only parts of the text is visible. Please see the attached screenshot. Tested using version 0.6.12 and 0.6.15. The plugin works correctly in Firefox 8 and Opera 10.0. Environment: Jenkins 1.478 Internet Explorer 8 Internet Explorer 10 Project: Jenkins Labels: plugin gui Priority: Major Reporter: Christian Tellefsen This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15601) Main dashboard takes minutes to load in browser
Márton Horváth commented on JENKINS-15601 Main dashboard takes minutes to load in browser We use Dashboard plugin also and have this long loading issue with current builds. Other views than main dashboard load normally. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12844) Information about locked builds don't show anywhere.
Kamil Wiraszka closed JENKINS-12844 as Wont Fix Information about locked builds dont show anywhere. no comment Change By: Kamil Wiraszka (26/Oct/12 1:27 PM) Status: Open Closed Resolution: WontFix This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15011) Jacoco Plugin 1.0.3 - no threshold config and displays broken graphic link
Ognjen Bubalo commented on JENKINS-15011 Jacoco Plugin 1.0.3 - no threshold config and displays broken graphic link Hi, This would be the next issue to fix. ogi This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15637) JIRA: missing component - 'debian-package-builder'
Marat Mavlyutov created JENKINS-15637 JIRA: missing component - debian-package-builder Issue Type: Task Assignee: Unassigned Components: jira Created: 26/Oct/12 2:12 PM Description: The debian-package-builder plugin should have a 'debian-package-builder' component alter ego in JIRA. The name is listed on the wikipage at https://wiki.jenkins-ci.org/display/JENKINS/Debian+Package+Builder+Plugin Project: Jenkins Priority: Major Reporter: Marat Mavlyutov This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15638) Xvfb 'display name offset' defaults to 0, not 1 as described, if unset
Fredrik Vihlborg updated JENKINS-15638 Xvfb display name offset defaults to 0, not 1 as described, if unset Change By: Fredrik Vihlborg (26/Oct/12 2:21 PM) Priority: Major Minor This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15638) Xvfb 'display name offset' defaults to 0, not 1 as described, if unset
Fredrik Vihlborg created JENKINS-15638 Xvfb display name offset defaults to 0, not 1 as described, if unset Issue Type: Bug Affects Versions: current Assignee: zregvart Components: xvfb Created: 26/Oct/12 2:21 PM Description: In 1.0.4, it seems like the "Xvfb display name offset" defaults to 0 when not set, instead of 1 as it says in the description? Jobs on executor #0 always get display :0 if "Xvfb specific displayname" and "Xvfb display name offset" are both left unset, and jobs running on executor #1 get display :1. Project: Jenkins Priority: Major Reporter: Fredrik Vihlborg This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15503) Test results lost on all past builds
Sven Amann commented on JENKINS-15503 Test results lost on all past builds For us the bug disappeared with upgrade to 467. Unfortunately now there is JENKINS-15601 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15503) Test results lost on all past builds
Sven Amann edited a comment on JENKINS-15503 Test results lost on all past builds For us the bug disappeared with upgrade to 467. Unfortunately now there is JENKINS-15601 (just so you know in case you consider an update) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15503) Test results lost on all past builds
piepera commented on JENKINS-15503 Test results lost on all past builds Sven, you mean 1.487, not 1.467, correct?? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15503) Test results lost on all past builds
Sven Amann commented on JENKINS-15503 Test results lost on all past builds Ups, sure do! Sorry for the typo! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15639) NPE When trying to see more builds in build history
jsirex created JENKINS-15639 NPE When trying to see more builds in build history Issue Type: Bug Assignee: Unassigned Components: core Created: 26/Oct/12 4:26 PM Description: Goto any job with many builds. In "build history" frame at the bottom click "more" (show more builds) NPE raiases Exception: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.487.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: i:formatDate java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.487.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: i:formatDate java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at
[JIRA] (JENKINS-15630) Build using Coverity Plugin fails because /tmp/.covlk file exists (Multiple jobs on executor)
Andrew Tolbert commented on JENKINS-15630 Build using Coverity Plugin fails because /tmp/.covlk file exists (Multiple jobs on executor) Unfortunately it looks like even after my attempted fix this can still possibly happen. There's a small window between when the code makes the .covlk check and when cov-build checks this file that it could be created again. I think this fix is still good, but perhaps there needs to be a Executor-level lock that prevents multiple builds using Coverity from executing at the same time. Does anyone have any experience with running multiple Jobs with Coverity at the same time on the same Executor? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15639) NPE When trying to see more builds in build history
Richard Mortimer resolved JENKINS-15639 as Duplicate NPE When trying to see more builds in build history Duplicate of JENKINS-15499 Change By: Richard Mortimer (26/Oct/12 4:32 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15639) NPE When trying to see more builds in build history
jsirex commented on JENKINS-15639 NPE When trying to see more builds in build history Thanks and sorry for duplication. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15639) NPE When trying to see more builds in build history
jsirex closed JENKINS-15639 as Duplicate NPE When trying to see more builds in build history Change By: jsirex (26/Oct/12 4:37 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-10502) Add an option to make archiving the artifacts non-fatal if they don't exist
bap commented on JENKINS-10502 Add an option to make archiving the artifacts non-fatal if they dont exist From above: "Install the flexible publish plugin and use the file exists or the files match run condition" Put the files that you want to archive in the run condition (File exists or Files match), it will then only run "Archive the artifacts" if those files are found. https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+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-15640) Deadlock in GroovyShell.init
Jesse Glick created JENKINS-15640 Deadlock in GroovyShell.init Issue Type: Bug Assignee: Jesse Glick Components: core Created: 26/Oct/12 5:24 PM Description: A user encountered a hung startup after around a minute of activity. Successive thread dumps showed that initialization was paused here: "ModelList.init" daemon prio=10 … in Object.wait() … java.lang.Thread.State: RUNNABLE at org.codehaus.groovy.util.ReferenceBundle.clinit(ReferenceBundle.java:37) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.init(MetaClassRegistryImpl.java:53) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.init(MetaClassRegistryImpl.java:61) at groovy.lang.GroovySystem.clinit(GroovySystem.java:29) at org.codehaus.groovy.runtime.InvokerHelper.clinit(InvokerHelper.java:49) at groovy.lang.GroovyObjectSupport.init(GroovyObjectSupport.java:32) at groovy.lang.Binding.init(Binding.java:34) at groovy.lang.GroovyShell.init(GroovyShell.java:82) at com.cloudbees.hudson.plugins.modeling.ModelList.init(ModelList.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at hudson.init.InitializerFinder.invoke(InitializerFinder.java:120) at hudson.init.InitializerFinder$TaskImpl.run(InitializerFinder.java:184) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$6.runTask(Jenkins.java:840) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) The line of code in question (assuming Groovy 1.8.5): ReferenceManager callBack = ReferenceManager.createCallBackedManager(queue); There were tons of request threads, mostly hung in something like: "Handling GET /…some page… : http-8080-2" daemon prio=10 … in Object.wait() … java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2aaabb3400a8 (a com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference) at java.lang.Object.wait(Object.java:502) at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.waitForValue(ComputingConcurrentHashMap.java:328) - locked 0x2aaabb3400a8 (a com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference) at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:160) at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393) at org.kohsuke.stapler.CachingScriptLoader.findScript(CachingScriptLoader.java:61) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:112) … But one was different: "Handling GET / : http-8080-1" daemon prio=10 … in Object.wait() … java.lang.Thread.State: RUNNABLE at org.codehaus.groovy.util.ReferenceManager.clinit(ReferenceManager.java:153) at org.codehaus.groovy.util.ManagedReference.clinit(ManagedReference.java:25) at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:107) at org.codehaus.groovy.reflection.ReflectionCache.clinit(ReflectionCache.java:52) at org.codehaus.groovy.classgen.asm.BytecodeHelper.box(BytecodeHelper.java:585) at org.codehaus.groovy.classgen.asm.BytecodeHelper.box(BytecodeHelper.java:577) at org.codehaus.groovy.classgen.asm.OperandStack.box(OperandStack.java:183) at org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:220) at
[JIRA] (JENKINS-15641) Poll SMC did not kick off a buid
Fory Horio created JENKINS-15641 Poll SMC did not kick off a buid Issue Type: Bug Affects Versions: current Assignee: jieryn Components: configure-job-column Created: 26/Oct/12 5:54 PM Description: I have a Poll SMC Schedule form of "30 */6 * * *" (every 6 hours). After upgrading to 1.486, the scheduling stopped working. Due Date: 26/Oct/12 12:00 AM Environment: Ubuntu precise 64bit. Jenkins 1.486 Project: Jenkins Priority: Minor Reporter: Fory Horio This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13521) Missing option E-mail notification (Post-build Actions)
Greg horvath commented on JENKINS-13521 Missing option E-mail notification (Post-build Actions) Good catch. The linked ticket is, I believe, the source of this issue. Need to bump that one. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15642) ArrayOutOfBounds exception with Maven build when triggered by SCM change
Ben McDonie created JENKINS-15642 ArrayOutOfBounds exception with Maven build when triggered by SCM change Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: maven Created: 26/Oct/12 6:56 PM Description: When I force the build, it succeeds. When the build is triggered by an SCM change, the job appears to build successfully until the very end of the "mvn clean install site" command where I get the following stack trace, which seems awfully familiar to some old lazily loaded job issues that I had a few versions ago... Waiting for Jenkins to finish collecting data mavenExecutionResult exceptions not empty message : Internal error: java.lang.ArrayIndexOutOfBoundsException: Assertion error: failing to load #3 DESC: lo=17,hi=3,size=106,size2=106 cause : Assertion error: failing to load #3 DESC: lo=17,hi=3,size=106,size2=106 Stack trace : org.apache.maven.InternalErrorException: Internal error: java.lang.ArrayIndexOutOfBoundsException: Assertion error: failing to load #3 DESC: lo=17,hi=3,size=106,size2=106 at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:98) at hudson.maven.Maven3Builder.call(Maven3Builder.java:64) 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(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ArrayIndexOutOfBoundsException: Assertion error: failing to load #3 DESC: lo=17,hi=3,size=106,size2=106 at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:418) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.maven.MavenModuleSetBuild.onLoad(MavenModuleSetBuild.java:140) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:432) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at
[JIRA] (JENKINS-15642) ArrayIndexOutOfBounds exception with Maven build when triggered by SCM change
Ben McDonie updated JENKINS-15642 ArrayIndexOutOfBounds exception with Maven build when triggered by SCM change Change By: Ben McDonie (26/Oct/12 6:57 PM) Summary: ArrayOutOfBounds ArrayIndexOutOfBounds exceptionwithMavenbuildwhentriggeredbySCMchange Labels: ArrayOutOfBoundsException ArrayIndexOutOfBounds lazy-loadingmavenscm This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath created JENKINS-15643 Consistent Out Of Memory Error When Adding 101st Build Node Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 26/Oct/12 7:20 PM Description: In our Jenkins install, we currently have 98 build nodes attached, with one offline (97 online nodes attached). When adding more nodes, we are consistently seeing an OutOfMemory error when attempting to add the 101st node. This error leaves Jenkins in a strange state the UI is still responsive, but no jobs can be submitted via the CLI. A restart allows jobs to once again be submitted. We have done a fair amount of cleanup to our plugin installs and decreasing build history, but the behavior is the same. We have not yet done any in-depth memory profiling on the machine to see what happens, but it seems that if it were a real OOM error, the point at which it would occur would be random. We see it consistently occur when adding the 101st build node. This leads me to believe that there is a hard-coded implicit limit on the number of online build nodes which can be attached to a single Jenkins instance at a time. If there is such a limit, it would be good to a) make that explicit and b) remove the limit. If no such limit exists, additional assistance on what could be contributing to these errors would be greatly appreciated. For reference, we are providing java args: -Xmx12G -Xms12G -XX:MaxNewSize=4G -XX:NewSize=4G -XX:MaxPermSize=512M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:ParallelGCThreads=6 -XX:CMSInitiatingOccupancyFraction=45 Environment: CentOS Project: Jenkins Labels: jenkins exception slave Priority: Critical Reporter: Greg horvath This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
SCM/JIRA link daemon commented on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/util/DirScanner.java core/src/main/java/hudson/util/FileVisitor.java http://jenkins-ci.org/commit/jenkins/af9977c1b28c2e212f707ab88b4f2ac561e37e50 Log: JENKINS-13202 Amelioration of problem: if the platform cannot read symlinks, fall back to visiting them as plain files or directories.(cherry picked from commit f50316b66a8e4761193c46f824fbd620ffccd6c0) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15587) Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39
Trevor Baker commented on JENKINS-15587 Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39 Am seeing the same exception @ 1.487 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14620) URLTrigger: Invalid configurations
Gregory Boissinot resolved JENKINS-14620 as Fixed URLTrigger: Invalid configurations Change By: Gregory Boissinot (26/Oct/12 7:54 PM) Status: InProgress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14620) URLTrigger: Invalid configurations
Gregory Boissinot commented on JENKINS-14620 URLTrigger: Invalid configurations Without any response, I made a release. Feel free to reopen the issue or raise an new issue if it the solution doesn't suit you. 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-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon commented on JENKINS-13368 Git plug-in included regions : build not triggered in case of mutiple commits in one push. Code changed in jenkins User: David Tanner Path: src/main/java/hudson/plugins/git/GitAPI.java src/main/java/hudson/plugins/git/GitSCM.java src/main/java/hudson/plugins/git/IGitAPI.java http://jenkins-ci.org/commit/git-plugin/8e139916a2937df84f06706bef85e5635c8f2e5f Log: JENKINS-13368 Merging in change as suggested. Also added a little null checking for the buildData being passed around now. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon commented on JENKINS-13368 Git plug-in included regions : build not triggered in case of mutiple commits in one push. Code changed in jenkins User: David Tanner Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/2bf5f34cb6679ad25ba1a873da3600ba2cd38181 Log: JENKINS-13368 Changing SHA1 of last build to buildData.lastBuild.revision.getSha1String(). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon commented on JENKINS-13368 Git plug-in included regions : build not triggered in case of mutiple commits in one push. Code changed in jenkins User: David Tanner Path: src/main/java/hudson/plugins/git/GitAPI.java src/test/java/hudson/plugins/git/GitSCMTest.java http://jenkins-ci.org/commit/git-plugin/f160f6f1472516695e9116ee5d8a83d0a668a0e8 Log: FIXED JENKINS-13368 Fixed GitAPI so it does both the older style of checking for changed files, and used the recommended change. Added test case for commits to included files that were changed further back than the last commit. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon resolved JENKINS-13368 as Fixed Git plug-in included regions : build not triggered in case of mutiple commits in one push. Change By: SCM/JIRA link daemon (26/Oct/12 7:58 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-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon commented on JENKINS-13368 Git plug-in included regions : build not triggered in case of mutiple commits in one push. Code changed in jenkins User: David Tanner Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/7a302e70d19339f992bf730dfaa095373c00fe7f Log: FIXED JENKINS-13368 Added one more level of null pointer checking for new code. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13368) Git plug-in included regions : build not triggered in case of mutiple commits in one push.
SCM/JIRA link daemon commented on JENKINS-13368 Git plug-in included regions : build not triggered in case of mutiple commits in one push. Code changed in jenkins User: Nicolas De loof Path: src/main/java/hudson/plugins/git/GitAPI.java src/main/java/hudson/plugins/git/GitSCM.java src/main/java/hudson/plugins/git/IGitAPI.java src/test/java/hudson/plugins/git/GitSCMTest.java http://jenkins-ci.org/commit/git-plugin/513d89b4a8a90980e23c02cce35cbdbc2ed069d0 Log: Merge pull request #106 from darthtanner/master JENKINS-13368 Fix for missing changes if multiple commits back. Compare: https://github.com/jenkinsci/git-plugin/compare/cb2e9c911b59...513d89b4a8a9 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12735) No upstream or downstream resolution with Maven version ranges
Alex Koon commented on JENKINS-12735 No upstream or downstream resolution with Maven version ranges I was the one that submitted the original patch and Kohsuke kindly integrated and cleaned up the code to provide Maven version range resolution. We have a live production system using this new version and it works very well - practically all module projects (in excess of 100 project modules and Maven reactor projects) are referenced by version ranges and projects up and downstream are initiated correctly when we commit code. Your issues with this failing isn't very clear - are you using version ranges and this is now failing (or initiating builds outside the range)? Or is this affecting your projects where the versions are defined by a hard version number? I imagine if the versions are defined (no version ranges) then this would have caused many more people grief. If you could clarify the project dependencies you have with real practical examples or better yet a unit test proving the failure that would help in resolving the issue and whether this is the correct JIRA to raise for this issue. I am happy to try and track the issue down subject to time but will need more information (note I am not a committer to the Jenkins project and have contributed this patch as we have a large project base that is very fluid and requires version ranges to function under Maven when we migrated from Ivy + Ant). Under maven-plugin/src/test/java/hudson/maven/MavenModuleTest.java are the unit tests for testing the resolution of up and downstream dependencies for reference. If you can supply a patch for this unit test with an example of your project structure and the breakage - this would help reproduce and track your issue down immensely. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12735) No upstream or downstream resolution with Maven version ranges
Jay Meyer commented on JENKINS-12735 No upstream or downstream resolution with Maven version ranges The new bug is not related to Maven version ranges. Instead, its about specific versions. My project has specific version numbers: e.g 1.1 vs. 1.2 in the pom dependencies specified. But when Jenkins reads them, it builds every OLD version of the downstream dependencies. A scenarios is spelled out in JENKINS-15367. And also bad, the old downstream versions are NOT built by the old upstream version, because Jenkins has associate the downstream projects with the incorrect upstream projects. So in this state I can no longer build version 1.1 of the system of projects. And the 1.2 version kicks off too many build, because it builds all of the 1.1 builds too. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12735) No upstream or downstream resolution with Maven version ranges
Jay Meyer edited a comment on JENKINS-12735 No upstream or downstream resolution with Maven version ranges The new bug is not related to Maven version ranges. Instead, its about specific versions. My project has specific version numbers: e.g 1.1 vs. 1.2 in the pom dependencies specified. But when Jenkins reads them, it builds every OLD version of the downstream dependencies. A scenario is spelled out in JENKINS-15367. And also bad, the old downstream versions are NOT built by the old upstream version, because Jenkins has associated the downstream projects with the incorrect upstream projects. So in this state I can no longer build version 1.1 of the system of projects. And the 1.2 version kicks off too many build, because it builds all of the 1.1 builds too. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14610) Full Admin rights needed to run slave WebStart
Michael Conlon commented on JENKINS-14610 Full Admin rights needed to run slave WebStart A workaround for this is to hack the url of the node to download the jnlp file. Add "slave-agent.jnlp" to the end of the url when you are at the node's page. Ex: http://server-name/computer/slave-name/slave-agent.jnlp This will download the jnlp file, which is what the Launch button does. Not ideal, but workable. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14664) URLTrigger: Takes many iterations to Trigger
Gregory Boissinot started work on JENKINS-14664 URLTrigger: Takes many iterations to Trigger Change By: Gregory Boissinot (26/Oct/12 8:49 PM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14664) URLTrigger: Takes many iterations to Trigger
Gregory Boissinot commented on JENKINS-14664 URLTrigger: Takes many iterations to Trigger I tested in a clean environment and I did not reproduce the issue. Do you have observed again the problem? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
cjo9900 commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Pull request created to solve the issue https://github.com/jenkinsci/git-plugin/pull/107 Includes the option to combine commits, if required. The default is to create separate builds for each build triggered with a git hash. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
hlau commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Thanks. Will this also solve the problem that only the git commit from the earliest trigger in a multiply triggered downstream job gets processed? In my example above, commit 4c41 from #415 never gets built (until I manually kick the job). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9615) JENKINS_HOME can't be on filer when using windows service
SCM/JIRA link daemon resolved JENKINS-9615 as Fixed JENKINS_HOME cant be on filer when using windows service Change By: SCM/JIRA link daemon (27/Oct/12 12:02 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9615) JENKINS_HOME can't be on filer when using windows service
SCM/JIRA link daemon commented on JENKINS-9615 JENKINS_HOME cant be on filer when using windows service Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/d56ba241ea4206bea0b2c4aa1178f8e3d46577f4 Log: FIXED JENKINS-9615 Integrated a fix made in Stapler. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15617) st:bind does not work inside l:ajax
Jesse Glick reopened JENKINS-15617 st:bind does not work inside l:ajax 51f508b breaks config page loading in IE 8 on XP. Change By: Jesse Glick (27/Oct/12 12:13 AM) Resolution: Fixed 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-15617) st:bind does not work inside l:ajax
Jesse Glick
commented on JENKINS-15617
st:bind does not work inside l:ajax
diff --git a/war/src/main/webapp/scripts/hudson-behavior.js b/war/src/main/webapp/scripts/hudson-behavior.js
index c88fc9f..4eb41b7 100644
--- a/war/src/main/webapp/scripts/hudson-behavior.js
+++ b/war/src/main/webapp/scripts/hudson-behavior.js
@@ -500,7 +500,7 @@ function isInsideRemovable(e) {
*/
function renderOnDemand(e,callback,noBehaviour) {
if (!e || !Element.hasClassName(e,"render-on-demand")) return;
-var proxy = geval(e.getAttribute("proxy"));
+var proxy = eval(e.getAttribute("proxy"));
proxy.render(function (t) {
var contextTagName = e.parentNode.tagName;
var c;
seems to fix it. Why is geval being used so widely?
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9615) JENKINS_HOME can't be on filer when using windows service
dogfood commented on JENKINS-9615 JENKINS_HOME cant be on filer when using windows service Integrated in jenkins_main_trunk #2035 FIXED JENKINS-9615 (Revision d56ba241ea4206bea0b2c4aa1178f8e3d46577f4) Result = UNSTABLE kohsuke : d56ba241ea4206bea0b2c4aa1178f8e3d46577f4 Files : core/pom.xml changelog.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-15644) Coverage report not published in Sonar
dmatag created JENKINS-15644 Coverage report not published in Sonar Issue Type: Bug Affects Versions: current Assignee: sonarteam Components: sonar Created: 27/Oct/12 1:40 AM Description: Sonar plugin versión 2.0 does not pubish coverage report when the maven goals are “-U clean cobertura:cobertura jar:jar install:install javadoc:javadoc javadoc:jar source:jar”, and sonar.dynamicAnalysis=reuseReports, while versión 1.8 does it fine. 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-15617) st:bind does not work inside l:ajax
Kohsuke Kawaguchi commented on JENKINS-15617 st:bind does not work inside l:ajax The idea behind geval is not to let evaluated script to access local in-scope variables as well as letting them put stuff into global scope, so I think it's sound to prefer geval as much as possible. Now, it turns out execScript always return null which means it can't be used at all where we need the return value. The next step is, who said eval on IE is broken? On my IE8 in the standards mode, "window.eval" seems to work as expected. MSDN backs me up and claims it has been there since IE6. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15617) st:bind does not work inside l:ajax
SCM/JIRA link daemon commented on JENKINS-15617 st:bind does not work inside l:ajax Code changed in jenkins User: Kohsuke Kawaguchi Path: war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/1c578ab5542bd20904c4a5e4ebcc80b42af31bbb Log: FIXED JENKINS-15617 execScript cannot return value 1, so I'm restricting its use to where we don't care about the return value. See ticket for more discussions 1 http://msdn.microsoft.com/en-us/library/ie/ms536420(v=vs.85).aspx This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15617) st:bind does not work inside l:ajax
SCM/JIRA link daemon resolved JENKINS-15617 as Fixed st:bind does not work inside l:ajax Change By: SCM/JIRA link daemon (27/Oct/12 2:21 AM) Status: Reopened Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15617) st:bind does not work inside l:ajax
dogfood commented on JENKINS-15617 st:bind does not work inside l:ajax Integrated in jenkins_main_trunk #2037 FIXED JENKINS-15617 (Revision 1c578ab5542bd20904c4a5e4ebcc80b42af31bbb) Result = UNSTABLE kohsuke : 1c578ab5542bd20904c4a5e4ebcc80b42af31bbb Files : war/src/main/webapp/scripts/hudson-behavior.js This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
