[JIRA] (JENKINS-13002) FileNotFoundException when trying to install version 1.22 of analysis collector plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-13002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner resolved JENKINS-13002. --- Resolution: Fixed I just made a new release 1.24. Hopefully this will be synched to the mirror again. > FileNotFoundException when trying to install version 1.22 of analysis > collector plugin > -- > > Key: JENKINS-13002 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13002 > Project: Jenkins > Issue Type: Bug > Components: update-center >Affects Versions: current > Environment: Linux - OpenSUSE 11.3, I am using 1.424.3 LTS Jenkins, > upgrading from 1.20 to 1.22 for analysis-collector >Reporter: keperry > > I receive the following error when trying to download the latest > analysis-collector plugin: > java.io.FileNotFoundException: > http://mirrors.jenkins-ci.org/plugins/analysis-collector/1.22/analysis-collector.hpi > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1458) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1452) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1106) > at > hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:621) > at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:952) > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1060) > at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:935) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > Caused by: java.io.FileNotFoundException: > http://mirrors.jenkins-ci.org/plugins/analysis-collector/1.22/analysis-collector.hpi > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1401) > at > sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2214) > at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:596) > at java.net.URLConnection.getContentLength(URLConnection.java:491) > at > hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:620) > ... 9 more > Note: I tried switching from the stable update url to the normal, with no > avail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13280) Fix for JENKINS-9118 breaks archival if symlink referent is in the archive
[ https://issues.jenkins-ci.org/browse/JENKINS-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160998#comment-160998 ] Brian Morris edited comment on JENKINS-13280 at 3/30/12 6:14 AM: - I am not familiar with the proper way to propose patches for git projects, nor have I attempted to compile Jenkins with this patch, but I believe this simple change would resolve this issue: {code} --- FilePath.java.orig 2012-03-29 23:09:54.0 -0700 +++ FilePath.java 2012-03-29 23:10:36.0 -0700 @@ -1805,12 +1805,12 @@ new FilePath(f).symlinkTo(te.getLinkName(), TaskListener.NULL); } else { IOUtils.copy(t,f); -} -f.setLastModified(te.getModTime().getTime()); -int mode = te.getMode()&0777; -if(mode!=0 && !Functions.isWindows()) // be defensive -_chmod(f,mode); +f.setLastModified(te.getModTime().getTime()); +int mode = te.getMode()&0777; +if(mode!=0 && !Functions.isWindows()) // be defensive +_chmod(f,mode); +} } } } catch(IOException e) { {code} was (Author: bsm_ghs): I am not familiar with the proper way to propose patches for git projects, nor have I attempted to compile Jenkins with this patch, but I believe this simple change would resolve this issue: --- FilePath.java.orig 2012-03-29 23:09:54.0 -0700 +++ FilePath.java 2012-03-29 23:10:36.0 -0700 @@ -1805,12 +1805,12 @@ new FilePath(f).symlinkTo(te.getLinkName(), TaskListener.NULL); } else { IOUtils.copy(t,f); -} -f.setLastModified(te.getModTime().getTime()); -int mode = te.getMode()&0777; -if(mode!=0 && !Functions.isWindows()) // be defensive -_chmod(f,mode); +f.setLastModified(te.getModTime().getTime()); +int mode = te.getMode()&0777; +if(mode!=0 && !Functions.isWindows()) // be defensive +_chmod(f,mode); +} } } } catch(IOException e) { > Fix for JENKINS-9118 breaks archival if symlink referent is in the archive > -- > > Key: JENKINS-13280 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13280 > Project: Jenkins > Issue Type: Bug > Components: clone-workspace >Reporter: Brian Morris >Assignee: abayer > > With the fix for JENKINS-9118, the archival process now attempts to preserve > symlinks, but in doing so it now fails to archive if the referent of a > symlink doesn't exist (yet). The problem is that it is apparently trying to > chmod the symlink (which it shouldn't be doing to extract a symlink anyway) > but that fails if the target of the symlink doesn't exist. In our case it > was because the target was also in the archive and hadn't been extracted yet. > Archiving artifacts > ERROR: Failed to archive artifacts: > linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* > hudson.util.IOException2: hudson.util.IOException2: Failed to extract > /home/jarvis/probebuild/jenkins/workspace/Tools_Linux86_Solaris2_P44/linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* > at hudson.FilePath.readFromTar(FilePath.java:1817) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) > at hudson.model.Run.run(Run.java:1435) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.io.IOException: Failed to chmod > /home/hal/jenkins/home/j
[JIRA] (JENKINS-13280) Fix for JENKINS-9118 breaks archival if symlink referent is in the archive
[ https://issues.jenkins-ci.org/browse/JENKINS-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160998#comment-160998 ] Brian Morris commented on JENKINS-13280: I am not familiar with the proper way to propose patches for git projects, nor have I attempted to compile Jenkins with this patch, but I believe this simple change would resolve this issue: --- FilePath.java.orig 2012-03-29 23:09:54.0 -0700 +++ FilePath.java 2012-03-29 23:10:36.0 -0700 @@ -1805,12 +1805,12 @@ new FilePath(f).symlinkTo(te.getLinkName(), TaskListener.NULL); } else { IOUtils.copy(t,f); -} -f.setLastModified(te.getModTime().getTime()); -int mode = te.getMode()&0777; -if(mode!=0 && !Functions.isWindows()) // be defensive -_chmod(f,mode); +f.setLastModified(te.getModTime().getTime()); +int mode = te.getMode()&0777; +if(mode!=0 && !Functions.isWindows()) // be defensive +_chmod(f,mode); +} } } } catch(IOException e) { > Fix for JENKINS-9118 breaks archival if symlink referent is in the archive > -- > > Key: JENKINS-13280 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13280 > Project: Jenkins > Issue Type: Bug > Components: clone-workspace >Reporter: Brian Morris >Assignee: abayer > > With the fix for JENKINS-9118, the archival process now attempts to preserve > symlinks, but in doing so it now fails to archive if the referent of a > symlink doesn't exist (yet). The problem is that it is apparently trying to > chmod the symlink (which it shouldn't be doing to extract a symlink anyway) > but that fails if the target of the symlink doesn't exist. In our case it > was because the target was also in the archive and hadn't been extracted yet. > Archiving artifacts > ERROR: Failed to archive artifacts: > linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* > hudson.util.IOException2: hudson.util.IOException2: Failed to extract > /home/jarvis/probebuild/jenkins/workspace/Tools_Linux86_Solaris2_P44/linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* > at hudson.FilePath.readFromTar(FilePath.java:1817) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) > at hudson.model.Run.run(Run.java:1435) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.io.IOException: Failed to chmod > /home/hal/jenkins/home/jobs/Tools_Linux86_Solaris2_P44/builds/2012-03-28_16-02-44/archive/linux86-deploy/.bochsrc > : No such file or directory > at hudson.FilePath._chmod(FilePath.java:1248) > at hudson.FilePath.readFromTar(FilePath.java:1813) > ... 12 more > at hudson.FilePath.copyRecursiveTo(FilePath.java:1736) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) > at hudson.model.Run.run(Run.java:1435) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe
[JIRA] (JENKINS-13284) ui-changes: Cannot load stylesheets during hudson-dev:run
OHTAKE Tomohiro created JENKINS-13284: - Summary: ui-changes: Cannot load stylesheets during hudson-dev:run Key: JENKINS-13284 URL: https://issues.jenkins-ci.org/browse/JENKINS-13284 Project: Jenkins Issue Type: Bug Components: ui-changes Reporter: OHTAKE Tomohiro Priority: Critical See https://github.com/jenkinsci/jenkins/commit/c4ab05d80fd2e2fb633143421517522c42538f7b#L1R432 Approaches: - Modify [maven-hudson-dev-plugin|https://github.com/jenkinsci/maven-hudson-dev-plugin] - Use [less.js|http://lesscss.org/#-client-side-usage] if Jenkins is running in developement mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13283) Unable to check workspace against depot in jenkins configuration on ubuntu
uday yatham created JENKINS-13283: - Summary: Unable to check workspace against depot in jenkins configuration on ubuntu Key: JENKINS-13283 URL: https://issues.jenkins-ci.org/browse/JENKINS-13283 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: ubuntu 11.10 Reporter: uday yatham Assignee: Rob Petti Fix For: current Attachments: bug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13282) ui-changes breadcrumbs should stick to top
OHTAKE Tomohiro created JENKINS-13282: - Summary: ui-changes breadcrumbs should stick to top Key: JENKINS-13282 URL: https://issues.jenkins-ci.org/browse/JENKINS-13282 Project: Jenkins Issue Type: New Feature Components: ui-changes Reporter: OHTAKE Tomohiro Comment by KK http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/61d571f2be751121/659c24674d13542c?show_docid=659c24674d13542c {quote} - The menu of the top banner doesn't seem very useful to me. Right now it always shows the same 4 things from the action menu of the top page, which is probably not what you intended. But even if it changes per page, I think it'd end up just repeating what's on the left. - I liked our recent breadcrumb that sticks to the top of the page. {quote} I agree with him because: - Jenkins pages are highly hierarchical. Breadcrumbs may become longer especially when we use JUnit Test Result, Analysis Plugins and Nested View. - The first item of the breadcumbs provides a link to root. I don't think a.brand should be always visible. - I seldom click "USER_NAME | log out" links. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13281) Import jQuery for ui-changes
OHTAKE Tomohiro created JENKINS-13281: - Summary: Import jQuery for ui-changes Key: JENKINS-13281 URL: https://issues.jenkins-ci.org/browse/JENKINS-13281 Project: Jenkins Issue Type: New Feature Components: ui-changes Reporter: OHTAKE Tomohiro Assignee: OHTAKE Tomohiro Bootstrap provides useful jQuery plugins. http://twitter.github.com/bootstrap/javascript.html In order to use them, we should import jQuery. Note 1: Jenkins uses prototype.js already. We have to handle conflicts. Note 2: We have to consider about compatibility with [jQuery UI Plugin|https://wiki.jenkins-ci.org/display/JENKINS/jQuery+Plugin] and [jQuery Plugin|https://wiki.jenkins-ci.org/display/JENKINS/jQuery+UI+Plugin]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13261) Style quick action dropdown menu
[ https://issues.jenkins-ci.org/browse/JENKINS-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160997#comment-160997 ] OHTAKE Tomohiro commented on JENKINS-13261: --- Did you mean "hetero-list-add" button by quick action dropdown menu? > Style quick action dropdown menu > > > Key: JENKINS-13261 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13261 > Project: Jenkins > Issue Type: Bug > Components: ui-changes >Reporter: Tom Bevers >Assignee: Tom Bevers > > Style the quick action dropdown menu to match the current UI-changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13259) Convert forms to use twitter bootstrap styling
[ https://issues.jenkins-ci.org/browse/JENKINS-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160996#comment-160996 ] OHTAKE Tomohiro commented on JENKINS-13259: --- I would like to try jQuery integration. I think integrating jQuery will make a lot of tests fail. 6 month ago, upgrading YUI to 2.9 makes 200 and more tests fail. We can decide who will implement each component after that. > Convert forms to use twitter bootstrap styling > -- > > Key: JENKINS-13259 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13259 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: Tom Bevers >Assignee: Tom Bevers > > Change all forms to use twitter bootstrap styling -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13204) Add "Poll Now" Feature
[ https://issues.jenkins-ci.org/browse/JENKINS-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160995#comment-160995 ] pixman20 commented on JENKINS-13204: For my purposes it would be for testing, but it is also nice to have for other users that want to run the polling script without waiting for the next event. This is especially useful for users who only have access to the "Poll Now" functionality and not to the configuration page. Having said that, I agree that it is best to keep ScriptTrigger compatible with earlier versions of Jenkins so that others may get more critical fixes/updates without being forced to upgrade their version of Jenkins. The 2 best options seem to be: 1) Close the issue 2) Put the issue on hold until ScriptTrigger needs to be updated to a newer Jenkins for other reasons. Thanks for looking into this. > Add "Poll Now" Feature > -- > > Key: JENKINS-13204 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13204 > Project: Jenkins > Issue Type: New Feature > Components: scripttrigger >Affects Versions: current > Environment: Windows XP server 2003 >Reporter: pixman20 >Assignee: gbois >Priority: Minor > > It would be very useful to have a "Poll Now" feature that causes the script > trigger to begin polling. > As it is now, you must either wait or manually configure the project's > schedule to be sooner (and then change it back after testing). > The "Poll Now" feature is currently available for SCM triggers, and it should > work identically to that functionality. > The "Poll Now" option would go right above the "ScriptTrigger Log" option > with the same icon except with a little green play triangle (at least if the > goal is to match the SCM trigger mechanism identically). > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160994#comment-160994 ] dogfood commented on JENKINS-12037: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1624|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1624/] [FIXED JENKINS-12037] CLI - I/O error in channel Chunked connection (Revision ea1b80aebe85a9414d5befd58e976d85818a258d) Result = SUCCESS richm : [ea1b80aebe85a9414d5befd58e976d85818a258d|https://github.com/jenkinsci/jenkins/commit/ea1b80aebe85a9414d5befd58e976d85818a258d] Files : * cli/src/main/java/hudson/cli/CLI.java * changelog.html > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.java:273) > at hudson.remoting.Channel.terminate(Channel.j
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160993#comment-160993 ] Richard Mortimer commented on JENKINS-12037: I've committed a change to the CLI code that brings the execution timeout in line with the ping period. This has the side effect of fixing the problem in my test environment (however the cli ping thread will busy wait roughly 75% of the time). In addition I've submitted pull request https://github.com/jenkinsci/remoting/pull/3 which will get rid of the busy waiting. > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.java:273) > at hudson.remoting.Channel.terminate(Channel.java:732) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139) > Caused by: java.io.IOExceptio
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160992#comment-160992 ] SCM/JIRA link daemon commented on JENKINS-12037: Code changed in jenkins User: Richard Mortimer Path: changelog.html cli/src/main/java/hudson/cli/CLI.java http://jenkins-ci.org/commit/jenkins/ea1b80aebe85a9414d5befd58e976d85818a258d Log: [FIXED JENKINS-12037] CLI - I/O error in channel Chunked connection Use a ping timeout of 3/4 of the ping interval instead of the default 4 minute timeout. This happens to workaround an issue in the remoting PingThread implementation which causes the ping to busy wait for the timeout period instead of keeping the channel alive. > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.j
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12037. Resolution: Fixed > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.java:273) > at hudson.remoting.Channel.terminate(Channel.java:732) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139) > Caused by: java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$Read
[JIRA] (JENKINS-13204) Add "Poll Now" Feature
[ https://issues.jenkins-ci.org/browse/JENKINS-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160991#comment-160991 ] gbois commented on JENKINS-13204: - 'Poll Now' SCM button is only available in a recent version of Jenkins. Clicking on this button calls the /poll action not available in Jenkins 1.410. ScriptTrigger is compatible to 1.410 and I would like to keep compatibility to 1.410. Moreover, I'm not convince of the utility of this feature. Is not only for test? > Add "Poll Now" Feature > -- > > Key: JENKINS-13204 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13204 > Project: Jenkins > Issue Type: New Feature > Components: scripttrigger >Affects Versions: current > Environment: Windows XP server 2003 >Reporter: pixman20 >Assignee: gbois >Priority: Minor > > It would be very useful to have a "Poll Now" feature that causes the script > trigger to begin polling. > As it is now, you must either wait or manually configure the project's > schedule to be sooner (and then change it back after testing). > The "Poll Now" feature is currently available for SCM triggers, and it should > work identically to that functionality. > The "Poll Now" option would go right above the "ScriptTrigger Log" option > with the same icon except with a little green play triangle (at least if the > goal is to match the SCM trigger mechanism identically). > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13280) Fix for JENKINS-9118 breaks archival if symlink referent is in the archive
Brian Morris created JENKINS-13280: -- Summary: Fix for JENKINS-9118 breaks archival if symlink referent is in the archive Key: JENKINS-13280 URL: https://issues.jenkins-ci.org/browse/JENKINS-13280 Project: Jenkins Issue Type: Bug Components: clone-workspace Reporter: Brian Morris Assignee: abayer With the fix for JENKINS-9118, the archival process now attempts to preserve symlinks, but in doing so it now fails to archive if the referent of a symlink doesn't exist (yet). The problem is that it is apparently trying to chmod the symlink (which it shouldn't be doing to extract a symlink anyway) but that fails if the target of the symlink doesn't exist. In our case it was because the target was also in the archive and hadn't been extracted yet. Archiving artifacts ERROR: Failed to archive artifacts: linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* hudson.util.IOException2: hudson.util.IOException2: Failed to extract /home/jarvis/probebuild/jenkins/workspace/Tools_Linux86_Solaris2_P44/linux86-deploy/*,solaris2-cross-linux86/*,test21/products/*,src/configuration/defaults/**/*,src/target/**/* at hudson.FilePath.readFromTar(FilePath.java:1817) at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.io.IOException: Failed to chmod /home/hal/jenkins/home/jobs/Tools_Linux86_Solaris2_P44/builds/2012-03-28_16-02-44/archive/linux86-deploy/.bochsrc : No such file or directory at hudson.FilePath._chmod(FilePath.java:1248) at hudson.FilePath.readFromTar(FilePath.java:1813) ... 12 more at hudson.FilePath.copyRecursiveTo(FilePath.java:1736) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$2.adapt(Channel.java:714) at hudson.remoting.Channel$2.adapt(Channel.java:709) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.FilePath.copyRecursiveTo(FilePath.java:1732) ... 11 more Caused by: java.io.IOException: Pipe is already closed at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83) at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171) at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118) at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126) at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:178) at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:135) at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:89) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410) at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351) at hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356) at hudson.org.apache.tools.tar.TarOutputStream.finish
[JIRA] (JENKINS-13279) Interface with Crowd embedded that runs in Jira
Iristyle created JENKINS-13279: -- Summary: Interface with Crowd embedded that runs in Jira Key: JENKINS-13279 URL: https://issues.jenkins-ci.org/browse/JENKINS-13279 Project: Jenkins Issue Type: New Feature Components: crowd2 Reporter: Iristyle Assignee: Thorsten Heit I don't know much about the details of how Crowd Embedded differs from Crowd standalone, but this is how we are sharing users between Jira and Confluence. We do not have an additional Crowd server. It would be awesome to be able to manage users for Jenkins in the same directory in Jira. There might be something useful here: https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Tutorials -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13245) Build not starting directly: pending - Waiting for next available executor on ...
[ https://issues.jenkins-ci.org/browse/JENKINS-13245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mwebber closed JENKINS-13245. - Resolution: Duplicate Closing, as duplicate of JENKINS-12994 > Build not starting directly: pending - Waiting for next available executor on > ... > - > > Key: JENKINS-13245 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13245 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Cees Bos >Priority: Critical > > Last Saterday we upgraded from 1.451 to 1.456 > Sometimes when we trigger a job it comes in the queue with the message: > (pending - Waiting for next available executor on .. servername ..) > This even happens when the slave is totally idle, the job can start directly. > After waiting for a minute it just starts ... > Nothings helps to speed up the execution process -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13245) Build not starting directly: pending - Waiting for next available executor on ...
[ https://issues.jenkins-ci.org/browse/JENKINS-13245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160989#comment-160989 ] Robert Cronk commented on JENKINS-13245: We're having the same problem and it's KILLING US! > Build not starting directly: pending - Waiting for next available executor on > ... > - > > Key: JENKINS-13245 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13245 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Cees Bos >Priority: Critical > > Last Saterday we upgraded from 1.451 to 1.456 > Sometimes when we trigger a job it comes in the queue with the message: > (pending - Waiting for next available executor on .. servername ..) > This even happens when the slave is totally idle, the job can start directly. > After waiting for a minute it just starts ... > Nothings helps to speed up the execution process -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13270) Occasional login failures using p4 ticket
[ https://issues.jenkins-ci.org/browse/JENKINS-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160988#comment-160988 ] Rob Petti commented on JENKINS-13270: - Has anything stopped working? Polling and/or builds for example? > Occasional login failures using p4 ticket > - > > Key: JENKINS-13270 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13270 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: 1.456 Jenkins with latest perforce plugin >Reporter: lestin >Priority: Minor > > Saw the following log whilst nothing has changed during the period: > > INFO: job_name_here #4437 main build action completed: SUCCESS > Mar 27, 2012 6:11:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:31:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:41:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:51:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:01:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:01:18 AM hudson.model.Run run > INFO: job_name_here #4438 main build action completed: SUCCESS > Mar 27, 2012 7:11:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:31:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Login with '/tools/perforce/2010.1/bin.linux26x86/p4' failed: Login > attempt failed: Password invalid. > Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Attempt to workaround p4 executable location failed > com.tek42.perforce.PerforceException: Could not run perforce command. > at > hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:88) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.p4Login(AbstractPerforceTemplate.java:596) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.login(AbstractPerforceTemplate.java:566) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:372) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) > at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61) > at > hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1325) > at > hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1019) > at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) > at hudson.scm.SCM.poll(SCM.java:373) > at hudson.model.AbstractProject.poll(AbstractProject.java:1340) > at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) > at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) > at > hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > 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:619) > Caused by: java.io.IOException: Cannot run program "/usr/bin/p4" (in > directory "/projects/jenkins/jenkins_home"): java.io.IOException: error=2, No > such file or directory > at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) > at hudson.Proc$LocalProc.(Proc.java:244) > at hudson.Proc$LocalProc.(Proc.java:216) > at hudson.Launcher$LocalLauncher.launch(Launcher.java:707) > at hudson.Launcher$ProcStarter.start(Launcher.java:338) > at > hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:79) > ... 19 more > Caused by: java.io.IOException: java.io.IOException: error=2, No such file or > directory > at j
[JIRA] (JENKINS-13270) Occasional login failures using p4 ticket
[ https://issues.jenkins-ci.org/browse/JENKINS-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti reassigned JENKINS-13270: --- Assignee: Rob Petti > Occasional login failures using p4 ticket > - > > Key: JENKINS-13270 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13270 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: 1.456 Jenkins with latest perforce plugin >Reporter: lestin >Assignee: Rob Petti >Priority: Minor > > Saw the following log whilst nothing has changed during the period: > > INFO: job_name_here #4437 main build action completed: SUCCESS > Mar 27, 2012 6:11:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:31:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:41:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 6:51:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:01:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:01:18 AM hudson.model.Run run > INFO: job_name_here #4438 main build action completed: SUCCESS > Mar 27, 2012 7:11:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:31:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Using p4 issued ticket. > Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Login with '/tools/perforce/2010.1/bin.linux26x86/p4' failed: Login > attempt failed: Password invalid. > Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate > login > WARNING: Attempt to workaround p4 executable location failed > com.tek42.perforce.PerforceException: Could not run perforce command. > at > hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:88) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.p4Login(AbstractPerforceTemplate.java:596) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.login(AbstractPerforceTemplate.java:566) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:372) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) > at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61) > at > hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1325) > at > hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1019) > at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) > at hudson.scm.SCM.poll(SCM.java:373) > at hudson.model.AbstractProject.poll(AbstractProject.java:1340) > at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) > at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) > at > hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > 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:619) > Caused by: java.io.IOException: Cannot run program "/usr/bin/p4" (in > directory "/projects/jenkins/jenkins_home"): java.io.IOException: error=2, No > such file or directory > at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) > at hudson.Proc$LocalProc.(Proc.java:244) > at hudson.Proc$LocalProc.(Proc.java:216) > at hudson.Launcher$LocalLauncher.launch(Launcher.java:707) > at hudson.Launcher$ProcStarter.start(Launcher.java:338) > at > hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:79) > ... 19 more > Caused by: java.io.IOException: java.io.IOException: error=2, No such file or > directory > at java.lang.UNIXProcess.(UNIXProcess.java:148) > at java.lang.Pr
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160987#comment-160987 ] Guillaume Bilodeau commented on JENKINS-13227: -- According to our CVS admin the output is correct in both situations. I'm afraid I don't know CVS well enough to say what's correct between both outputs. Can someone try something similar in a different CVS environment? > CVS plugin 2.1 does not detect changes > -- > > Key: JENKINS-13227 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Guillaume Bilodeau > Labels: cvs > > As presented in the user group: > https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 > We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS > repository for a few weeks now, without any problems. The CVS plugin (v1.6) > was using the local cvsnt install. > We've since upgraded the CVS plugin to version 2.1 (by manually pinning the > plugin) and since then, CVS changes are not detected. The CVS polling log is > triggered properly, tons of "cvs rlog" instructions are sent, but at the end > "No changes" is displayed. > Using CVS plugin 1.6 the cvs polling command looked like this (executed at > 5:26:21 PM EDT): > cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D > "Thursday, March 22, 2012 9:26:21 PM UTC" > Using CVS plugin 2.1, the last cvs checkout command looked like this > (executed at 11:56:16 AM EDT): > cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 > 11:56:16 EDT -d portailInt portailInt > We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13278) Avator images should be shown on people page
[ https://issues.jenkins-ci.org/browse/JENKINS-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-13278: -- Assignee: oxcafebabe > Avator images should be shown on people page > > > Key: JENKINS-13278 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13278 > Project: Jenkins > Issue Type: Improvement > Components: avatar >Reporter: Ulli Hafner >Assignee: oxcafebabe >Priority: Minor > > Since a couple of releases Jenkins provides an API for avatar images. These > images will show up on the People page (http://yourjenkins/people). The > [Gravatar Plug-in|https://wiki.jenkins-ci.org/display/JENKINS/Gravatar+plugin > ] already makes use of this API. Please update yur plugin to support this API > so that these images will also be visible at this place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
[ https://issues.jenkins-ci.org/browse/JENKINS-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti resolved JENKINS-13271. - Resolution: Fixed > Perforce plugin throws null pointer exception upon encountering deleted user > > > Key: JENKINS-13271 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.457 > P4 Plugin 1.3.11 >Reporter: S Stack >Assignee: Rob Petti >Priority: Blocker > > P4 plugin throws a null pointer exception causing job failure when running a > "p4 -s users " where is a once active, now > deleted account. The only workaround appears to be to recreate the deleted > account which consumes a Perforce license. I have verified this workaround > twice with two different deleted accounts. > Example failure output: > Started by user cmteam > Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace > Using master perforce client: ciqa-some-deploy > [workspace] $ p4 workspace -o ciqa-some-deploy > Saving modified client ciqa-some-deploy > [workspace] $ p4 -s client -i > Clearing workspace... > Note: .repository directory in workspace (if exists) is skipped. > Cleared workspace. > Last build changeset: 79972 > [workspace] $ p4 -s changes -s submitted -m 1 > //ciqa-some-deploy/...@somelabel-4.1.0.0 > [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 > [workspace] $ p4 describe -s 85075 > [workspace] $ p4 -G where //... > [workspace] $ p4 describe -s 85012 > [workspace] $ p4 describe -s 85005 > [workspace] $ p4 describe -s 84668 > > [workspace] $ p4 describe -s 81052 > [workspace] $ p4 describe -s 81031 > [workspace] $ p4 describe -s 81029 > [workspace] $ p4 -s users valid-user-1 > [workspace] $ p4 user -o valid-user-1 > [workspace] $ p4 -s users valid-user-2 > [workspace] $ p4 user -o valid-user-2 > [workspace] $ p4 -s users deleted-user > FATAL: null > java.lang.NullPointerException > at > hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) > at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > And of course the job fails at this point. > Note that "p4 -s users deleted-user" > returns > error: deleted-user - no such user(s). > exit: 0 > while "p4 -s users valid-user" > returns > info: valid-user (Valid User) accessed 2012/03/29 > exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13278) Avator images should be shown on people page
Ulli Hafner created JENKINS-13278: - Summary: Avator images should be shown on people page Key: JENKINS-13278 URL: https://issues.jenkins-ci.org/browse/JENKINS-13278 Project: Jenkins Issue Type: Improvement Components: avatar Reporter: Ulli Hafner Priority: Minor Since a couple of releases Jenkins provides an API for avatar images. These images will show up on the People page (http://yourjenkins/people). The [Gravatar Plug-in|https://wiki.jenkins-ci.org/display/JENKINS/Gravatar+plugin ] already makes use of this API. Please update yur plugin to support this API so that these images will also be visible at this place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7390) Subversion-Plugin - Ignore svn:external
[ https://issues.jenkins-ci.org/browse/JENKINS-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160986#comment-160986 ] Martin Scherer commented on JENKINS-7390: - What is the current status of this issue? Some of our developers use svn:externals for boost, which adds 1.2 millions line of code to every checkout that is made. This code is also checked by our static code analysis job every time, which drastically increases the runtime. Manually excluding in every seperate tool would be a total mess. In addition copying workspace to other slaves takes minutes now (because boost has so many files). Please add support for svn checkout/update --ignore-externals Thank you, Martin > Subversion-Plugin - Ignore svn:external > --- > > Key: JENKINS-7390 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7390 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Affects Versions: current >Reporter: Marc Schoechlin > > Subversion plugin should provide a configuration switch to ignore > svn-externals. > Many projects integrate opensource projects in the following way: > $ svn propset svn:externals "getline > http://anonsvn.mono-project.com/source/trunk/mcs/tools/csharp"; . > If the subversion plugin now polls the sourcecode repository of a project > which is using > externals every minute - all 3rd party subversion repositories are also > polled. > This might be a DDOS for public opensource projects. > Typically developers use certain svn tag releases in their projects - > therefore it is not > ncessary to poll this tag-releases every minute. > In other words: Something like "svn --ignore-externals up ." is needed... > Subversion plugin should provide the following configuration options: > {code} > [X] Fetch svn:externals > [ ] Fetch svn:externals if checkout does not exist > [ ] Fetch svn:externals periodically > (1d) (m)inutes/(h)ours/(d)ays > {code} > If you have hints how to trigger this in the svn-api of org.tmatesoft.svn.* / > how to implement this > please let me know... > Regards > Marc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11428) Display "All Failed Tests" in test result page optionnally
[ https://issues.jenkins-ci.org/browse/JENKINS-11428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160985#comment-160985 ] Chad Werdon commented on JENKINS-11428: --- Just wondering if anyone has taken a look at this. It would be great if "All Failed Tests" was optional or minimizable. > Display "All Failed Tests" in test result page optionnally > -- > > Key: JENKINS-11428 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11428 > Project: Jenkins > Issue Type: Improvement > Components: junit >Reporter: stibbons > > I simply propose to make the "All Failed Tests" list of failed test > optionnally in the test result page. Personally, I would prefer not to have > this, it breaks readability. Or being able to place it after "All Tests". > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11938) Jenkins loses builds when restarted
[ https://issues.jenkins-ci.org/browse/JENKINS-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160984#comment-160984 ] Dorin Marinca commented on JENKINS-11938: - In fact the file pointed by in build.xml files is saved (not lost) in \jobs\\builds\\fileParameters\<*here*>. So there should be an issue on selection of value stored in . Instead storing some temp file (that someone would remove for freeing the temp), jenkins should store the path to the file stored anyway under the build directory. > Jenkins loses builds when restarted > --- > > Key: JENKINS-11938 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11938 > Project: Jenkins > Issue Type: Bug > Components: other, versionnumber >Affects Versions: current > Environment: tomcat 7.0.22 > windows server 2008 r2 >Reporter: Ben Dean > > Jenkins version 1.437 > If I stop the Apache Tomcat windows service, a bunch of my builds disappear > from the history of the jobs. The missing builds are still on disk in the > build folder, it just doesn't "find" them when making the history list. > The jobs that lose history use the version number plugin and I had recently > changed the version format from "4.3.${BUILDS_ALL_TIME}" to > "4.4.${BUILDS_ALL_TIME}". The builds that disappear are all those after I > changed this format. Also affects jobs that are downstream from those with > version number changes. > I could not find any Component related to the build history for a job. If > someone knows what that should be feel free to change this. Also, sorry if > there's not enough (or to much) information, this is the first Jenkins bug I > have filed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
[ https://issues.jenkins-ci.org/browse/JENKINS-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160983#comment-160983 ] S Stack commented on JENKINS-13271: --- Tested successfully. A deleted user is merely ignored. Many thanks for the ultra-fast turnaround! How I tested: I installed the plugin on 1 of several CI servers. I have a small job which builds a "helloWorld" Java app in Maven. I created a P4 user named "temp" and as "temp", checked in a change to //depot/test/helloWorld/... Immediately after the submit completed, as the P4 admin, I deleted user "temp". Only on the patched CI server did the job succeed. > Perforce plugin throws null pointer exception upon encountering deleted user > > > Key: JENKINS-13271 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.457 > P4 Plugin 1.3.11 >Reporter: S Stack >Assignee: Rob Petti >Priority: Blocker > > P4 plugin throws a null pointer exception causing job failure when running a > "p4 -s users " where is a once active, now > deleted account. The only workaround appears to be to recreate the deleted > account which consumes a Perforce license. I have verified this workaround > twice with two different deleted accounts. > Example failure output: > Started by user cmteam > Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace > Using master perforce client: ciqa-some-deploy > [workspace] $ p4 workspace -o ciqa-some-deploy > Saving modified client ciqa-some-deploy > [workspace] $ p4 -s client -i > Clearing workspace... > Note: .repository directory in workspace (if exists) is skipped. > Cleared workspace. > Last build changeset: 79972 > [workspace] $ p4 -s changes -s submitted -m 1 > //ciqa-some-deploy/...@somelabel-4.1.0.0 > [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 > [workspace] $ p4 describe -s 85075 > [workspace] $ p4 -G where //... > [workspace] $ p4 describe -s 85012 > [workspace] $ p4 describe -s 85005 > [workspace] $ p4 describe -s 84668 > > [workspace] $ p4 describe -s 81052 > [workspace] $ p4 describe -s 81031 > [workspace] $ p4 describe -s 81029 > [workspace] $ p4 -s users valid-user-1 > [workspace] $ p4 user -o valid-user-1 > [workspace] $ p4 -s users valid-user-2 > [workspace] $ p4 user -o valid-user-2 > [workspace] $ p4 -s users deleted-user > FATAL: null > java.lang.NullPointerException > at > hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) > at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > And of course the job fails at this point. > Note that "p4 -s users deleted-user" > returns > error: deleted-user - no such user(s). > exit: 0 > while "p4 -s users valid-user" > returns > info: valid-user (Valid User) accessed 2012/03/29 > exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13276) Error Installing SDK Components: "Error: Flag '-o' is not valid for 'update sdk'."
[ https://issues.jenkins-ci.org/browse/JENKINS-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Orr closed JENKINS-13276. - Resolution: Cannot Reproduce Please upgrade to version 2.2 of the plugin. > Error Installing SDK Components: "Error: Flag '-o' is not valid for 'update > sdk'." > -- > > Key: JENKINS-13276 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13276 > Project: Jenkins > Issue Type: Bug > Components: android-emulator >Affects Versions: current > Environment: Slave: > Linux server-74490 3.0.0-12-virtual #20-Ubuntu SMP Fri Oct 7 18:19:02 UTC > 2011 x86_64 x86_64 x86_64 GNU/Linux > Ubuntu 11.10 > Login as non-super user 'jenkins' >Reporter: Bill Magnuson >Assignee: Christopher Orr >Priority: Blocker > Attachments: Screen Shot 2012-03-29 at 2.40.33 PM.png > > > I'm experiencing the following errors when android-emulator attempts to setup > an emulator automatically: > [android] Installing the 'android-8' SDK component(s)... > $ /var/jenkins/tools/android-sdk/tools/android update sdk -o -u -t android-8 > Error: Flag '-o' is not valid for 'update sdk'. > Followed by: > [android] Creating Android AVD: > /home/jenkins/.android/avd/hudson_en-US_160_WVGA_android-8.avd > [android] Failed to run AVD creation command > Error: Target id is not valid. Use 'android list targets' to get the > target ids. > > [android] Could not create Android emulator: Failed to run AVD creation > command > The full build log is below and my Android Emulator settings from the build > configuration are included in an attached screenshot. > -Bill > The full build output: > tarted by user Bill Magnuson > Building remotely on hpcloud-android-build in workspace > /var/jenkins/workspace/android-sdk > Checkout:android-sdk / /var/jenkins/workspace/android-sdk - > hudson.remoting.Channel@11260d:hpcloud-android-build > Using strategy: Default > Last Built Revision: Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 > (origin/HEAD, origin/develop) > Checkout:android-sdk / /var/jenkins/workspace/android-sdk - > hudson.remoting.LocalChannel@7b7597b6 > Fetching changes from 1 remote Git repository > Fetching upstream changes from g...@github.com:Appboy/android-sdk.git > Seen branch in repository origin/HEAD > Seen branch in repository origin/develop > Seen branch in repository origin/master > Commencing build of Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 > (origin/HEAD, origin/develop) > Checking out Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 (origin/HEAD, > origin/develop) > Warning : There are multiple branch changesets here > [android] No Android SDK found; let's install it automatically... > Downloading and installing Android SDK from > http://dl.google.com/android/android-sdk_r16-linux.tgz > [android] Base SDK installed successfully > [android] Going to install required Android SDK components... > [android] Installing the 'platform-tool,tool' SDK component(s)... > $ /var/jenkins/tools/android-sdk/tools/android update sdk -o -u -t > platform-tool,tool > Refresh Sources: > Fetching https://dl-ssl.google.com/android/repository/addons_list-1.xml > Validate XML > Parse XML > Fetched Add-ons List successfully > Refresh Sources > Fetching URL: https://dl-ssl.google.com/android/repository/repository-5.xml > Validate XML: https://dl-ssl.google.com/android/repository/repository-5.xml > Parse XML:https://dl-ssl.google.com/android/repository/repository-5.xml > Fetching URL: https://dl-ssl.google.com/android/repository/addon.xml > Validate XML: https://dl-ssl.google.com/android/repository/addon.xml > Fetching URL: http://dl.htcdev.com/sdk/addon.xml > Validate XML: http://dl.htcdev.com/sdk/addon.xml > Parse XML:http://dl.htcdev.com/sdk/addon.xml > Fetching URL: http://software.intel.com/sites/landingpage/android/addon.xml > Validate XML: http://software.intel.com/sites/landingpage/android/addon.xml > Parse XML:http://software.intel.com/sites/landingpage/android/addon.xml > Fetching URL: http://www.echobykyocera.com/download/echo_repository.xml > Validate XML: http://www.echobykyocera.com/download/echo_repository.xml > Parse XML:http://www.echobykyocera.com/download/echo_repository.xml > Fetching URL: http://developer.lgmobile.com/sdk/android/repository.xml > Validate XML: http://developer.lgmobile.com/sdk/android/repository.xml > Parse XML:http://developer.lgmobile.com/sdk/android/repository.xml > Fetching URL: http://android-sdk-addons.motodevupdate.com/addons.xml > Validate XML: http://android-sdk-addons.motodevupdate.com/addons.xml > Parse XML:http://android-sdk-addons.motodevupdate.com/addons.xml > Fetching URL: > http://innova
[JIRA] (JENKINS-13277) Global environment variables are not being resolved in Email Notification Recipients list for maven 2/3 projects
[ https://issues.jenkins-ci.org/browse/JENKINS-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160981#comment-160981 ] jfreej commented on JENKINS-13277: -- Update: Simple build parameters are not working either. When I create a build parameter "ALERT_EMAIL_LIST" and set "Email Notification > Recipients" to "${ALERT_EMAIL_LIST}", I see: "Sending e-mails to: ${ALERT_EMAIL_LIST}@test.com". Again, this only applies to . > Global environment variables are not being resolved in Email Notification > Recipients list for maven 2/3 projects > > > Key: JENKINS-13277 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13277 > Project: Jenkins > Issue Type: Bug > Components: email-ext, notification >Affects Versions: current >Reporter: jfreej > > When using a global environment variable, defined in "Manage Jenkins > > Configure System > Environment Variables" (e.g. "ALERT_EMAIL_LIST"), in the > "Email Notification > Recipients" list of a maven 2/3 project (e.g. > "${ALERT_EMAIL_LIST}") the environment variable is not resolved. In the > console output we see: "Sending e-mails to: ${ALERT_EMAIL_LIST}@test.com". > Note that it DOES work in an "free-style software project". > So, it does not work within , but it does > work within . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9688) Build runs on master without executor and get stuck
[ https://issues.jenkins-ci.org/browse/JENKINS-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160980#comment-160980 ] wbauer commented on JENKINS-9688: - I see the same issue sporadically (Jenkins 1.454 currently). The build seems to be stuck in the assignment phase and no thread or sockets refers to it at all. The build is not visible in any queue or listing except on the job itself. The build shows: "Started 2 hr 1 min ago Build is being executed for null on master" . This build is not killable meaning that I have to restart the master to get rid of the build... > Build runs on master without executor and get stuck > --- > > Key: JENKINS-9688 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9688 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: protocol7b > > In the ASF Jenkins, we do not allow builds to run on master. Thus, we have > set the number of executors on master to zero. Even so, one build recently > (https://builds.apache.org/hudson/job/Axis2/774/) got assigned to run on > master. The build is configured with a label to run on one of the slaves, but > somehow Jenkins assigned it incorrectly. > Running on master also meant it got stuck, presumably due to the lack of > executors, without any way of stopping it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13277) Global environment variables are not being resolved in Email Notification Recipients list for maven 2/3 projects
jfreej created JENKINS-13277: Summary: Global environment variables are not being resolved in Email Notification Recipients list for maven 2/3 projects Key: JENKINS-13277 URL: https://issues.jenkins-ci.org/browse/JENKINS-13277 Project: Jenkins Issue Type: Bug Components: email-ext, notification Affects Versions: current Reporter: jfreej When using a global environment variable, defined in "Manage Jenkins > Configure System > Environment Variables" (e.g. "ALERT_EMAIL_LIST"), in the "Email Notification > Recipients" list of a maven 2/3 project (e.g. "${ALERT_EMAIL_LIST}") the environment variable is not resolved. In the console output we see: "Sending e-mails to: ${ALERT_EMAIL_LIST}@test.com". Note that it DOES work in an "free-style software project". So, it does not work within , but it does work within . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13276) Error Installing SDK Components: "Error: Flag '-o' is not valid for 'update sdk'."
Bill Magnuson created JENKINS-13276: --- Summary: Error Installing SDK Components: "Error: Flag '-o' is not valid for 'update sdk'." Key: JENKINS-13276 URL: https://issues.jenkins-ci.org/browse/JENKINS-13276 Project: Jenkins Issue Type: Bug Components: android-emulator Affects Versions: current Environment: Slave: Linux server-74490 3.0.0-12-virtual #20-Ubuntu SMP Fri Oct 7 18:19:02 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 11.10 Login as non-super user 'jenkins' Reporter: Bill Magnuson Assignee: Christopher Orr Priority: Blocker Attachments: Screen Shot 2012-03-29 at 2.40.33 PM.png I'm experiencing the following errors when android-emulator attempts to setup an emulator automatically: [android] Installing the 'android-8' SDK component(s)... $ /var/jenkins/tools/android-sdk/tools/android update sdk -o -u -t android-8 Error: Flag '-o' is not valid for 'update sdk'. Followed by: [android] Creating Android AVD: /home/jenkins/.android/avd/hudson_en-US_160_WVGA_android-8.avd [android] Failed to run AVD creation command Error: Target id is not valid. Use 'android list targets' to get the target ids. [android] Could not create Android emulator: Failed to run AVD creation command The full build log is below and my Android Emulator settings from the build configuration are included in an attached screenshot. -Bill The full build output: tarted by user Bill Magnuson Building remotely on hpcloud-android-build in workspace /var/jenkins/workspace/android-sdk Checkout:android-sdk / /var/jenkins/workspace/android-sdk - hudson.remoting.Channel@11260d:hpcloud-android-build Using strategy: Default Last Built Revision: Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 (origin/HEAD, origin/develop) Checkout:android-sdk / /var/jenkins/workspace/android-sdk - hudson.remoting.LocalChannel@7b7597b6 Fetching changes from 1 remote Git repository Fetching upstream changes from g...@github.com:Appboy/android-sdk.git Seen branch in repository origin/HEAD Seen branch in repository origin/develop Seen branch in repository origin/master Commencing build of Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 (origin/HEAD, origin/develop) Checking out Revision 9ae6c42ae35fedc557cc4b67748868e57bc9db53 (origin/HEAD, origin/develop) Warning : There are multiple branch changesets here [android] No Android SDK found; let's install it automatically... Downloading and installing Android SDK from http://dl.google.com/android/android-sdk_r16-linux.tgz [android] Base SDK installed successfully [android] Going to install required Android SDK components... [android] Installing the 'platform-tool,tool' SDK component(s)... $ /var/jenkins/tools/android-sdk/tools/android update sdk -o -u -t platform-tool,tool Refresh Sources: Fetching https://dl-ssl.google.com/android/repository/addons_list-1.xml Validate XML Parse XML Fetched Add-ons List successfully Refresh Sources Fetching URL: https://dl-ssl.google.com/android/repository/repository-5.xml Validate XML: https://dl-ssl.google.com/android/repository/repository-5.xml Parse XML:https://dl-ssl.google.com/android/repository/repository-5.xml Fetching URL: https://dl-ssl.google.com/android/repository/addon.xml Validate XML: https://dl-ssl.google.com/android/repository/addon.xml Fetching URL: http://dl.htcdev.com/sdk/addon.xml Validate XML: http://dl.htcdev.com/sdk/addon.xml Parse XML:http://dl.htcdev.com/sdk/addon.xml Fetching URL: http://software.intel.com/sites/landingpage/android/addon.xml Validate XML: http://software.intel.com/sites/landingpage/android/addon.xml Parse XML:http://software.intel.com/sites/landingpage/android/addon.xml Fetching URL: http://www.echobykyocera.com/download/echo_repository.xml Validate XML: http://www.echobykyocera.com/download/echo_repository.xml Parse XML:http://www.echobykyocera.com/download/echo_repository.xml Fetching URL: http://developer.lgmobile.com/sdk/android/repository.xml Validate XML: http://developer.lgmobile.com/sdk/android/repository.xml Parse XML:http://developer.lgmobile.com/sdk/android/repository.xml Fetching URL: http://android-sdk-addons.motodevupdate.com/addons.xml Validate XML: http://android-sdk-addons.motodevupdate.com/addons.xml Parse XML:http://android-sdk-addons.motodevupdate.com/addons.xml Fetching URL: http://innovator.samsungmobile.com/android/repository/repository.xml Validate XML: http://innovator.samsungmobile.com/android/repository/repository.xml Parse XML: http://innovator.samsungmobile.com/android/repository/repository.xml Fetching URL: http://developer.sonyericsson.com/edk/android/repository.xml Validate XML: http://developer.sonyericsson.com/edk/android/repository.xml Parse XML:http://developer.sonyericsson.com/edk/android/repository.x
[JIRA] (JENKINS-7554) GIT_BRANCH not set when multiple branches are selected for build
[ https://issues.jenkins-ci.org/browse/JENKINS-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160979#comment-160979 ] Carsten Brandt commented on JENKINS-7554: - Had it working with 1.454, updated to 1.457 and it now fails... Whats the problem with setting GIT_BRANCH env variable to the branch currently beeing built while build step (exec shell, etc...) > GIT_BRANCH not set when multiple branches are selected for build > > > Key: JENKINS-7554 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7554 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current > Environment: Windows 7 >Reporter: jadaks31 >Assignee: abayer > > When trying to identify what branch the current build are on i found that the > GIT_BRANCH environment variable is not set when more then a single branch is > selected to be built. > I have seen that getSingleBranch(build) returns null when that happens > GIT_BRANCH is not exposed to the build. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10860) Unable to determine Maven version
[ https://issues.jenkins-ci.org/browse/JENKINS-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160978#comment-160978 ] Antti Koivisto commented on JENKINS-10860: -- Same problem here. When using a custom workspace, the Artifactory plugin fails with this: {code} FATAL: Unable to determine Maven version java.lang.RuntimeException: Unable to determine Maven version at org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.isMavenVersionValid(MavenExtractorEnvironment.java:135) at org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.buildEnvVars(MavenExtractorEnvironment.java:88) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:850) at hudson.maven.AbstractMavenBuild.getEnvironment(AbstractMavenBuild.java:59) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:156) at hudson.model.AbstractBuild$AbstractRunner.decideWorkspace(AbstractBuild.java:437) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:457) at hudson.model.Run.run(Run.java:1408) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.lang.NullPointerException at org.jfrog.hudson.util.MavenVersionHelper.isAtLeast(MavenVersionHelper.java:103) at org.jfrog.hudson.util.MavenVersionHelper.isAtLeastVersion(MavenVersionHelper.java:75) at org.jfrog.hudson.util.MavenVersionHelper.isAtLeastResolutionCapableVersion(MavenVersionHelper.java:65) at org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.isMavenVersionValid(MavenExtractorEnvironment.java:133) ... 10 more {code} When custom workspace is not used, this exception is not thrown. * Jenkins ver. 1.454 * Artifactory Plugin 2.0.5 > Unable to determine Maven version > - > > Key: JENKINS-10860 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10860 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Linux SuSE 10.3 > Jenkins 1.427 > Artifactory 2.3.4.1 > Artifactory plugin 2.0.4 >Reporter: Giuliano Ribeiro >Assignee: yossis >Priority: Critical > > Using Maven 2/3 project to build my project works fine. > But When I active "Deploy artifacts to Artifactory" in Post Build Actions, > build stop to work and show me this stack in Console Output: > FATAL: Unable to determine Maven version > java.lang.RuntimeException: Unable to determine Maven version > at > org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.isMavenVersionValid(MavenExtractorEnvironment.java:106) > at > org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.buildEnvVars(MavenExtractorEnvironment.java:73) > at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:804) > at > hudson.maven.AbstractMavenBuild.getEnvironment(AbstractMavenBuild.java:59) > at > hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:165) > at > hudson.model.AbstractBuild$AbstractRunner.decideWorkspace(AbstractBuild.java:419) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:436) > at hudson.model.Run.run(Run.java:1376) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:479) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) > Caused by: java.lang.NullPointerException > at > org.jfrog.hudson.util.MavenVersionHelper.isAtLeast(MavenVersionHelper.java:103) > at > org.jfrog.hudson.util.MavenVersionHelper.isAtLeastVersion(MavenVersionHelper.java:75) > at > org.jfrog.hudson.util.MavenVersionHelper.isAtLeastResolutionCapableVersion(MavenVersionHelper.java:65) > at > org.jfrog.hudson.maven3.extractor.MavenExtractorEnvironment.isMavenVersionValid(MavenExtractorEnvironment.java:104) > ... 10 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10319) Ability to change the name "Compiler" as seen in a lot of the displays
[ https://issues.jenkins-ci.org/browse/JENKINS-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160977#comment-160977 ] dogfood commented on JENKINS-10319: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_warnings #379|http://ci.jenkins-ci.org/job/plugins_warnings/379/] [JENKINS-10319] Fixed serialization of results. (Revision b7030aa6d639355591c53a88aaea53c0a412e3f9) Result = SUCCESS Ulli Hafner : Files : * src/main/java/hudson/plugins/warnings/WarningsBuildHistory.java * pom.xml * src/main/java/hudson/plugins/warnings/WarningsAnnotationsAggregator.java * src/main/java/hudson/plugins/warnings/WarningsPublisher.java * src/test/java/hudson/plugins/warnings/WarningsResultTest.java * src/main/java/hudson/plugins/warnings/WarningsResult.java > Ability to change the name "Compiler" as seen in a lot of the displays > -- > > Key: JENKINS-10319 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10319 > Project: Jenkins > Issue Type: New Feature > Components: warnings >Reporter: Nigel Robbins >Assignee: Ulli Hafner >Priority: Minor > Attachments: compilerWarningsBuild.png, compilerWarningsIcon.png, > compilerWarningsList.png, compilerWarningsTrend.png > > > Hi, > Would it be possible to configure the label "Compiler Warnings". > I am using the Warnings plugin to show FlawFinder issues. > Seeing text like "FlawFinder Warnings" or maybe "FlawFinder Issues" would > enhance my display. > Can the parser name (e.g. FlawFinder in my case) be used instead of the text > "Compiler" ? > Or, maybe the ability to change the label "Compiler Warnings" to something > else ? > I can see the text "Compiler Warnings" in a number of places which I've > attached screenshots of. The "Compiler Warnings" text may also appear > elsewhere. > Great plugin by the way ! > Many thanks, > Nigel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10319) Ability to change the name "Compiler" as seen in a lot of the displays
[ https://issues.jenkins-ci.org/browse/JENKINS-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160976#comment-160976 ] SCM/JIRA link daemon commented on JENKINS-10319: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/warnings/WarningsAnnotationsAggregator.java src/main/java/hudson/plugins/warnings/WarningsBuildHistory.java src/main/java/hudson/plugins/warnings/WarningsPublisher.java src/main/java/hudson/plugins/warnings/WarningsResult.java src/test/java/hudson/plugins/warnings/WarningsResultTest.java http://jenkins-ci.org/commit/warnings-plugin/b7030aa6d639355591c53a88aaea53c0a412e3f9 Log: [JENKINS-10319] Fixed serialization of results. > Ability to change the name "Compiler" as seen in a lot of the displays > -- > > Key: JENKINS-10319 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10319 > Project: Jenkins > Issue Type: New Feature > Components: warnings >Reporter: Nigel Robbins >Assignee: Ulli Hafner >Priority: Minor > Attachments: compilerWarningsBuild.png, compilerWarningsIcon.png, > compilerWarningsList.png, compilerWarningsTrend.png > > > Hi, > Would it be possible to configure the label "Compiler Warnings". > I am using the Warnings plugin to show FlawFinder issues. > Seeing text like "FlawFinder Warnings" or maybe "FlawFinder Issues" would > enhance my display. > Can the parser name (e.g. FlawFinder in my case) be used instead of the text > "Compiler" ? > Or, maybe the ability to change the label "Compiler Warnings" to something > else ? > I can see the text "Compiler Warnings" in a number of places which I've > attached screenshots of. The "Compiler Warnings" text may also appear > elsewhere. > Great plugin by the way ! > Many thanks, > Nigel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160974#comment-160974 ] dogfood commented on JENKINS-12994: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1623|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1623/] [FIX JENKINS-12994] Quiet period is blocking other jobs in queue (Revision 394e9d6c0488fae6834d97a158a018abb31f3179) Update changelog for JENKINS-12994 (Revision 07b3f2cccb077df85617f2748f9b329528bc263b) Result = SUCCESS Vincent Latombe : [394e9d6c0488fae6834d97a158a018abb31f3179|https://github.com/jenkinsci/jenkins/commit/394e9d6c0488fae6834d97a158a018abb31f3179] Files : * core/src/main/java/hudson/model/Queue.java Vincent Latombe : [07b3f2cccb077df85617f2748f9b329528bc263b|https://github.com/jenkinsci/jenkins/commit/07b3f2cccb077df85617f2748f9b329528bc263b] Files : * changelog.html > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo >Priority: Critical > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13129) Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup
[ https://issues.jenkins-ci.org/browse/JENKINS-13129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160975#comment-160975 ] dogfood commented on JENKINS-13129: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1623|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1623/] [Fixed JENKINS-13129] Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup (Revision 2453985ca5f4cb2c824466d132fe3658020b72fe) Result = SUCCESS alexlehm : [2453985ca5f4cb2c824466d132fe3658020b72fe|https://github.com/jenkinsci/jenkins/commit/2453985ca5f4cb2c824466d132fe3658020b72fe] Files : * test/src/test/java/hudson/PluginManagerTest2.java * core/src/main/java/hudson/PluginManager.java > Updating built-in plugins doesn't work, the file doesn't get pinned and is > overwritten on the next startup > -- > > Key: JENKINS-13129 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13129 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: jenkins 1.456, tomcat 7.0.25, java 1.6.0-31 running on > windows vista >Reporter: Alex Lehmann >Assignee: Alex Lehmann > > I still cannot update cvs or subversion plugins without manually creating a > .pinned file. > When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file > is installed into the plugin dir, but no cvs.jpi.pinned file is created. When > restarting the tomcat server, the file is replaced by the 1.6 version from > the war directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
[ https://issues.jenkins-ci.org/browse/JENKINS-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160973#comment-160973 ] Rob Petti commented on JENKINS-13271: - Can you please test with this snapshot and let me know if it works for you? http://ci.jenkins-ci.org/job/plugins_perforce/206/artifact/target/perforce.hpi > Perforce plugin throws null pointer exception upon encountering deleted user > > > Key: JENKINS-13271 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.457 > P4 Plugin 1.3.11 >Reporter: S Stack >Assignee: Rob Petti >Priority: Blocker > > P4 plugin throws a null pointer exception causing job failure when running a > "p4 -s users " where is a once active, now > deleted account. The only workaround appears to be to recreate the deleted > account which consumes a Perforce license. I have verified this workaround > twice with two different deleted accounts. > Example failure output: > Started by user cmteam > Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace > Using master perforce client: ciqa-some-deploy > [workspace] $ p4 workspace -o ciqa-some-deploy > Saving modified client ciqa-some-deploy > [workspace] $ p4 -s client -i > Clearing workspace... > Note: .repository directory in workspace (if exists) is skipped. > Cleared workspace. > Last build changeset: 79972 > [workspace] $ p4 -s changes -s submitted -m 1 > //ciqa-some-deploy/...@somelabel-4.1.0.0 > [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 > [workspace] $ p4 describe -s 85075 > [workspace] $ p4 -G where //... > [workspace] $ p4 describe -s 85012 > [workspace] $ p4 describe -s 85005 > [workspace] $ p4 describe -s 84668 > > [workspace] $ p4 describe -s 81052 > [workspace] $ p4 describe -s 81031 > [workspace] $ p4 describe -s 81029 > [workspace] $ p4 -s users valid-user-1 > [workspace] $ p4 user -o valid-user-1 > [workspace] $ p4 -s users valid-user-2 > [workspace] $ p4 user -o valid-user-2 > [workspace] $ p4 -s users deleted-user > FATAL: null > java.lang.NullPointerException > at > hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) > at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > And of course the job fails at this point. > Note that "p4 -s users deleted-user" > returns > error: deleted-user - no such user(s). > exit: 0 > while "p4 -s users valid-user" > returns > info: valid-user (Valid User) accessed 2012/03/29 > exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12545) Jenkins should build all tracked branches that have changed when triggered by Github
[ https://issues.jenkins-ci.org/browse/JENKINS-12545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160971#comment-160971 ] Carsten Brandt commented on JENKINS-12545: -- anyway it would be nice if it was possible to force build for every branch > Jenkins should build all tracked branches that have changed when triggered by > Github > > > Key: JENKINS-12545 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12545 > Project: Jenkins > Issue Type: Bug > Components: github > Environment: Jenkins 1.448, Github-api plugin 1.16, Github plugin > 1.0, Git plugin 1.1.15 > Ubuntu 9.04 >Reporter: Leon Miller-Out > Labels: git, github, webhook > > I have several projects configured to build multiple branches and set to > build when changes are pushed to Github. For example, several projects have > origin/master and origin/development registered. It seems to build the > correct branch when I push to a single branch on Github, but it fails to > behave as expected in the following situations: > 1. If I push to two branches at once, only one of them gets built. It should > build both of them. This probably has something to do with the changelog for > 1.1.12 at https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin that talks > about picking branches. > 2. If I push to one branch, then push to a second branch while the first is > being built, the second one never gets built. > This bug seems to force me to set up a separate job for each branch I want to > build, which works poorly with the Github webhook (it build all of the > branches every time). I can't switch to polling (I think) because my slave > systems are volatile and Jenkins seems to lose track of which ref was built > last when the slave it was built on goes away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12545) Jenkins should build all tracked branches that have changed when triggered by Github
[ https://issues.jenkins-ci.org/browse/JENKINS-12545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160970#comment-160970 ] Carsten Brandt commented on JENKINS-12545: -- might be expected behavior when they are dependend: http://jenkins.361315.n4.nabble.com/Building-multiple-branches-with-Jenkins-td3547909.html > Jenkins should build all tracked branches that have changed when triggered by > Github > > > Key: JENKINS-12545 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12545 > Project: Jenkins > Issue Type: Bug > Components: github > Environment: Jenkins 1.448, Github-api plugin 1.16, Github plugin > 1.0, Git plugin 1.1.15 > Ubuntu 9.04 >Reporter: Leon Miller-Out > Labels: git, github, webhook > > I have several projects configured to build multiple branches and set to > build when changes are pushed to Github. For example, several projects have > origin/master and origin/development registered. It seems to build the > correct branch when I push to a single branch on Github, but it fails to > behave as expected in the following situations: > 1. If I push to two branches at once, only one of them gets built. It should > build both of them. This probably has something to do with the changelog for > 1.1.12 at https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin that talks > about picking branches. > 2. If I push to one branch, then push to a second branch while the first is > being built, the second one never gets built. > This bug seems to force me to set up a separate job for each branch I want to > build, which works poorly with the Github webhook (it build all of the > branches every time). I can't switch to polling (I think) because my slave > systems are volatile and Jenkins seems to lose track of which ref was built > last when the slave it was built on goes away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13186) Environment variables don't work in the CVS ROOT Field
[ https://issues.jenkins-ci.org/browse/JENKINS-13186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160969#comment-160969 ] Torresz Daniel commented on JENKINS-13186: -- Yes, in any another fileds the environment variables are work, but not in the cvs root field. > Environment variables don't work in the CVS ROOT Field > -- > > Key: JENKINS-13186 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13186 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Latest Jenkins and latest CVS plugin >Reporter: Torresz Daniel > > I set up a new environment variable(MYCVSROOT -> > :pserver:myuser:mypassw@myhost:/mycvsrepo) on the configure system page. > I created a new job and I wanted to use this environment variable(%MYCVSROOT% > or $MYCVSROOT) in the Source Code Management/CVS Root field, but the value of > the MYCVSROOT does not substitued. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13129) Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup
[ https://issues.jenkins-ci.org/browse/JENKINS-13129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160968#comment-160968 ] SCM/JIRA link daemon commented on JENKINS-13129: Code changed in jenkins User: Andrew Bayer Path: core/src/main/java/hudson/PluginManager.java test/src/test/java/hudson/PluginManagerTest2.java http://jenkins-ci.org/commit/jenkins/860cc9eb61a6a3212e4b8589ac11a74b59b1fcf7 Log: Merge pull request #418 from alexlehm/master Fixed JENKINS-13129: Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup > Updating built-in plugins doesn't work, the file doesn't get pinned and is > overwritten on the next startup > -- > > Key: JENKINS-13129 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13129 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: jenkins 1.456, tomcat 7.0.25, java 1.6.0-31 running on > windows vista >Reporter: Alex Lehmann >Assignee: Alex Lehmann > > I still cannot update cvs or subversion plugins without manually creating a > .pinned file. > When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file > is installed into the plugin dir, but no cvs.jpi.pinned file is created. When > restarting the tomcat server, the file is replaced by the 1.6 version from > the war directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160967#comment-160967 ] SCM/JIRA link daemon commented on JENKINS-12994: Code changed in jenkins User: Andrew Bayer Path: changelog.html core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/e4abef20fbdb71971085e7507d7fff4b92676368 Log: Merge pull request #419 from Vlatombe/jenkins-12994 [FIX JENKINS-12994] Quiet period is blocking other jobs in queue > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo >Priority: Critical > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
[ https://issues.jenkins-ci.org/browse/JENKINS-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160966#comment-160966 ] dogfood commented on JENKINS-13271: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_perforce #206|http://ci.jenkins-ci.org/job/plugins_perforce/206/] [JENKINS-13271] fix NPE when parsing changes containing a deleted perforce user (Revision 2a92a469d667e9ed1f1c252cb4e00728a341ef85) Result = SUCCESS Rob Petti : Files : * src/main/java/hudson/plugins/perforce/PerforceSCM.java > Perforce plugin throws null pointer exception upon encountering deleted user > > > Key: JENKINS-13271 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.457 > P4 Plugin 1.3.11 >Reporter: S Stack >Assignee: Rob Petti >Priority: Blocker > > P4 plugin throws a null pointer exception causing job failure when running a > "p4 -s users " where is a once active, now > deleted account. The only workaround appears to be to recreate the deleted > account which consumes a Perforce license. I have verified this workaround > twice with two different deleted accounts. > Example failure output: > Started by user cmteam > Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace > Using master perforce client: ciqa-some-deploy > [workspace] $ p4 workspace -o ciqa-some-deploy > Saving modified client ciqa-some-deploy > [workspace] $ p4 -s client -i > Clearing workspace... > Note: .repository directory in workspace (if exists) is skipped. > Cleared workspace. > Last build changeset: 79972 > [workspace] $ p4 -s changes -s submitted -m 1 > //ciqa-some-deploy/...@somelabel-4.1.0.0 > [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 > [workspace] $ p4 describe -s 85075 > [workspace] $ p4 -G where //... > [workspace] $ p4 describe -s 85012 > [workspace] $ p4 describe -s 85005 > [workspace] $ p4 describe -s 84668 > > [workspace] $ p4 describe -s 81052 > [workspace] $ p4 describe -s 81031 > [workspace] $ p4 describe -s 81029 > [workspace] $ p4 -s users valid-user-1 > [workspace] $ p4 user -o valid-user-1 > [workspace] $ p4 -s users valid-user-2 > [workspace] $ p4 user -o valid-user-2 > [workspace] $ p4 -s users deleted-user > FATAL: null > java.lang.NullPointerException > at > hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) > at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > And of course the job fails at this point. > Note that "p4 -s users deleted-user" > returns > error: deleted-user - no such user(s). > exit: 0 > while "p4 -s users valid-user" > returns > info: valid-user (Valid User) accessed 2012/03/29 > exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13204) Add "Poll Now" Feature
[ https://issues.jenkins-ci.org/browse/JENKINS-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160965#comment-160965 ] pixman20 commented on JENKINS-13204: I am currently running the latest Jenkins (1.457) and the latest of the scripttrigger plugin (0.16). By simply selecting the "Poll SCM" checkbox (utilizing CVS plugin for SCM) in the configuration history I am able to see the "Poll Now" button on the main job page, however when deselecting "Poll SCM" and selecting the "[ScriptTrigger] - Poll with a shell or batch script" checkbox there is no "Poll Now"-like button to hit. That then requires manual tweaking of the configuration file to get the trigger to poll on demand by setting the schedule for a time within the next minute. If the button can be added it would probably be best to have it called something along the lines of "Poll ScriptTrigger" since both "Poll SCM" and the scripttrigger polling checkboxes can be selected allowing for multiple "Poll Now" buttons on the main job page. I'm not sure if that is the information that you wanted, so let me know if you need more. If this seems to "out of the way" for very minor functionality, I'd be alright with closing this issue. However, it if it's fairly simple then it would be very nice to have (and cut time testing out my script :). > Add "Poll Now" Feature > -- > > Key: JENKINS-13204 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13204 > Project: Jenkins > Issue Type: New Feature > Components: scripttrigger >Affects Versions: current > Environment: Windows XP server 2003 >Reporter: pixman20 >Assignee: gbois >Priority: Minor > > It would be very useful to have a "Poll Now" feature that causes the script > trigger to begin polling. > As it is now, you must either wait or manually configure the project's > schedule to be sooner (and then change it back after testing). > The "Poll Now" feature is currently available for SCM triggers, and it should > work identically to that functionality. > The "Poll Now" option would go right above the "ScriptTrigger Log" option > with the same icon except with a little green play triangle (at least if the > goal is to match the SCM trigger mechanism identically). > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160964#comment-160964 ] Eric Co commented on JENKINS-13264: --- false false ericco@10.10.10.251:/home/cvsroot lib/flac-1.2.1 HEAD false drv/linux/2.4/fuse HEAD false -1 false true false true false false true false false false false true > fail checkout 2 modules with different path > --- > > Key: JENKINS-13264 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 > Project: Jenkins > Issue Type: Bug > Components: cvs > Environment: linux >Reporter: Eric Co > > I create two cvs modules with the path > lib/flac-1.2.1 > drv/linux/fuse > when it check out, got the error: > cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 > lib/flac-1.2.1 > cvs [checkout aborted]: could not change directory to requested checkout > directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
[ https://issues.jenkins-ci.org/browse/JENKINS-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160963#comment-160963 ] SCM/JIRA link daemon commented on JENKINS-13271: Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/perforce-plugin/2a92a469d667e9ed1f1c252cb4e00728a341ef85 Log: [JENKINS-13271] fix NPE when parsing changes containing a deleted perforce user > Perforce plugin throws null pointer exception upon encountering deleted user > > > Key: JENKINS-13271 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.457 > P4 Plugin 1.3.11 >Reporter: S Stack >Assignee: Rob Petti >Priority: Blocker > > P4 plugin throws a null pointer exception causing job failure when running a > "p4 -s users " where is a once active, now > deleted account. The only workaround appears to be to recreate the deleted > account which consumes a Perforce license. I have verified this workaround > twice with two different deleted accounts. > Example failure output: > Started by user cmteam > Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace > Using master perforce client: ciqa-some-deploy > [workspace] $ p4 workspace -o ciqa-some-deploy > Saving modified client ciqa-some-deploy > [workspace] $ p4 -s client -i > Clearing workspace... > Note: .repository directory in workspace (if exists) is skipped. > Cleared workspace. > Last build changeset: 79972 > [workspace] $ p4 -s changes -s submitted -m 1 > //ciqa-some-deploy/...@somelabel-4.1.0.0 > [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 > [workspace] $ p4 describe -s 85075 > [workspace] $ p4 -G where //... > [workspace] $ p4 describe -s 85012 > [workspace] $ p4 describe -s 85005 > [workspace] $ p4 describe -s 84668 > > [workspace] $ p4 describe -s 81052 > [workspace] $ p4 describe -s 81031 > [workspace] $ p4 describe -s 81029 > [workspace] $ p4 -s users valid-user-1 > [workspace] $ p4 user -o valid-user-1 > [workspace] $ p4 -s users valid-user-2 > [workspace] $ p4 user -o valid-user-2 > [workspace] $ p4 -s users deleted-user > FATAL: null > java.lang.NullPointerException > at > hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) > at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > And of course the job fails at this point. > Note that "p4 -s users deleted-user" > returns > error: deleted-user - no such user(s). > exit: 0 > while "p4 -s users valid-user" > returns > info: valid-user (Valid User) accessed 2012/03/29 > exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160962#comment-160962 ] Uwe Stuehler commented on JENKINS-9882: --- New issue opened: JENKINS-13275 > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting for retry > and a bit later (this starts repeating): > [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no > more request handlers available in the pool > [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no > more request handlers available in the pool > Jenkins then stops handling requests successfully - at the beginning > intermittently, but finally basically failing almost all of the > requests. > Using VisualVM I can see that there is a thousand RequestHandlerThread > threads in wait state, and that over 1200 file descriptors are > currently in use. > I think the requests start failing because winstone has a this limit: > private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; > as it doesn't seem to be running out of available fds (apparently 8192 > is the maximum in this setup). > When I restart jenkins I can verify a slow buildup of threads and used > file descriptors: > * 10 minutes after restart: 136 live threads, 256 fds used > * 20 minutes: 150 threads, 271 fds > * 30 minutes: 161 threads, 280 fds > * 110 minutes: 255 threads, 376 fds > I've looked at the repository version of winstone, and looking at the > code there seems to be a race condition in handling of the request > handler pool. > When a request is received by ObjectPool.handleRequest, it looks for > an available request handler from unusedRequestHandlerThreads and > calls commenceRequestHandling on the available thread. > commenceRequestHandling in turn does this.notifyAll() to wake up the > thread. So far so good. However when the thread has finished > processing the request, it calls > this.objectPool.releaseRequestHandler(this) and *then* waits. I think > here's a race condition, since what can happen is that object pool > called (CALL) and request handler thread (RH) can interleave like > this: > # RH (in RequestHandler.run): this.objectPool.releaseRequestHandler(this) > # RH (in ObjectPool.releaseRequestHandler): > this.unusedRequestHandlerThreads.add(rh) > # CALL (in ObjectPool.handleRequest): take RH from unusedRequestHandlerThreads > # CALL (in ObjectPool.handleRequest): rh.commenceRequestHandling(socket, > listener); > # CALL (in RequestHandler.commenceRequestHandling): this.notifyAll() > # RH (in ObjectPool.run): this.wait() > Since notify is lost (no waiters), this.wait() in the last step will > hang forever. This will leak a file descriptor since the socket given > to be processed is never reclaimed, and threads are effectively lost > as Winstone will then create more RequestHandlers. > Now, this is of course a winstone problem, but its development seems > to be d-e-a-d at least looking at its bug tracker. As long as this > problem affect Jenkins, I'd still classify it as a Jenkins problem too. > I've put this into the winstone tracker too: > https://sourceforge.net/tracker/?func=detail&aid=3308285&group_id=98922&atid=622497 > Workaround: Use Tomcat, not embedded winstone (that's what I'm doing now). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13275) Jenkins stops handling HTTP/AJP requests after some time
Uwe Stuehler created JENKINS-13275: -- Summary: Jenkins stops handling HTTP/AJP requests after some time Key: JENKINS-13275 URL: https://issues.jenkins-ci.org/browse/JENKINS-13275 Project: Jenkins Issue Type: Bug Components: core Environment: Jenkins 1.457 from official package, Debian 6.0.4, x86_64 (amd64) Reporter: Uwe Stuehler Priority: Critical After about a day of normal operation, Jenkins will suddenly stop handling HTTP and AJP requests. JNLP slave connections are still handled normally, jobs continue to run and notifications are delivered as usual. Whenever this happens, we see connections being accept()ed, but the system call trace reveals that nothing actually happens with the new file descriptor. jstack output shows 200 {{RequestHandlerThread}} threads with exactly the same backtrace: {noformat} "RequestHandlerThread[#871]" daemon prio=10 tid=0x7fee8527a800 nid=0xf2c runnable [0x7fee7d493000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.DataInputStream.readFully(DataInputStream.java:178) at java.io.DataInputStream.readFully(DataInputStream.java:152) at winstone.ajp13.Ajp13IncomingPacket.(Ajp13IncomingPacket.java:60) at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:170) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:67) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160961#comment-160961 ] Marc Günther commented on JENKINS-9882: --- Uwe Stuehler wrote: > Is 200 a fixed limit on the number of request handler threads? It is. From winstone.ObjectsPool.java:35 {code}private int MAX_REQUEST_HANDLERS_IN_POOL = 200;{code} > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting for retry > and a bit later (this starts repeating): > [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no > more request handlers available in the pool > [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no > more request handlers available in the pool > Jenkins then stops handling requests successfully - at the beginning > intermittently, but finally basically failing almost all of the > requests. > Using VisualVM I can see that there is a thousand RequestHandlerThread > threads in wait state, and that over 1200 file descriptors are > currently in use. > I think the requests start failing because winstone has a this limit: > private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; > as it doesn't seem to be running out of available fds (apparently 8192 > is the maximum in this setup). > When I restart jenkins I can verify a slow buildup of threads and used > file descriptors: > * 10 minutes after restart: 136 live threads, 256 fds used > * 20 minutes: 150 threads, 271 fds > * 30 minutes: 161 threads, 280 fds > * 110 minutes: 255 threads, 376 fds > I've looked at the repository version of winstone, and looking at the > code there seems to be a race condition in handling of the request > handler pool. > When a request is received by ObjectPool.handleRequest, it looks for > an available request handler from unusedRequestHandlerThreads and > calls commenceRequestHandling on the available thread. > commenceRequestHandling in turn does this.notifyAll() to wake up the > thread. So far so good. However when the thread has finished > processing the request, it calls > this.objectPool.releaseRequestHandler(this) and *then* waits. I think > here's a race condition, since what can happen is that object pool > called (CALL) and request handler thread (RH) can interleave like > this: > # RH (in RequestHandler.run): this.objectPool.releaseRequestHandler(this) > # RH (in ObjectPool.releaseRequestHandler): > this.unusedRequestHandlerThreads.add(rh) > # CALL (in ObjectPool.handleRequest): take RH from unusedRequestHandlerThreads > # CALL (in ObjectPool.handleRequest): rh.commenceRequestHandling(socket, > listener); > # CALL (in RequestHandler.commenceRequestHandling): this.notifyAll() > # RH (in ObjectPool.run): this.wait() > Since notify is lost (no waiters), this.wait() in the last step will > hang forever. This will leak a file descriptor since the socket given > to be processed is never reclaimed, and threads are effectively lost > as Winstone will then create more RequestHandlers. > Now, this is of course a winstone problem, but its development seems > to be d-e-a-d at least looking at its bug tracker. As long as this > problem affect Jenkins, I'd still classify it as a Jenkins problem too. > I've put this into the winstone tracker too: > https://sourceforge.net/tracker/?func=detail&aid=3308285&group_id=98922&atid=622497 > Workaround: Use Tomcat, not embedded winstone (that's what I'm doing now). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160960#comment-160960 ] Uwe Stuehler commented on JENKINS-9882: --- FWIW: The number 200 is indeed the thread [pool size limit|https://github.com/jenkinsci/winstone/blob/master/src/java/winstone/ObjectPool.java#L35]. > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting for retry > and a bit later (this starts repeating): > [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no > more request handlers available in the pool > [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no > more request handlers available in the pool > Jenkins then stops handling requests successfully - at the beginning > intermittently, but finally basically failing almost all of the > requests. > Using VisualVM I can see that there is a thousand RequestHandlerThread > threads in wait state, and that over 1200 file descriptors are > currently in use. > I think the requests start failing because winstone has a this limit: > private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; > as it doesn't seem to be running out of available fds (apparently 8192 > is the maximum in this setup). > When I restart jenkins I can verify a slow buildup of threads and used > file descriptors: > * 10 minutes after restart: 136 live threads, 256 fds used > * 20 minutes: 150 threads, 271 fds > * 30 minutes: 161 threads, 280 fds > * 110 minutes: 255 threads, 376 fds > I've looked at the repository version of winstone, and looking at the > code there seems to be a race condition in handling of the request > handler pool. > When a request is received by ObjectPool.handleRequest, it looks for > an available request handler from unusedRequestHandlerThreads and > calls commenceRequestHandling on the available thread. > commenceRequestHandling in turn does this.notifyAll() to wake up the > thread. So far so good. However when the thread has finished > processing the request, it calls > this.objectPool.releaseRequestHandler(this) and *then* waits. I think > here's a race condition, since what can happen is that object pool > called (CALL) and request handler thread (RH) can interleave like > this: > # RH (in RequestHandler.run): this.objectPool.releaseRequestHandler(this) > # RH (in ObjectPool.releaseRequestHandler): > this.unusedRequestHandlerThreads.add(rh) > # CALL (in ObjectPool.handleRequest): take RH from unusedRequestHandlerThreads > # CALL (in ObjectPool.handleRequest): rh.commenceRequestHandling(socket, > listener); > # CALL (in RequestHandler.commenceRequestHandling): this.notifyAll() > # RH (in ObjectPool.run): this.wait() > Since notify is lost (no waiters), this.wait() in the last step will > hang forever. This will leak a file descriptor since the socket given > to be processed is never reclaimed, and threads are effectively lost > as Winstone will then create more RequestHandlers. > Now, this is of course a winstone problem, but its development seems > to be d-e-a-d at least looking at its bug tracker. As long as this > problem affect Jenkins, I'd still classify it as a Jenkins problem too. > I've put this into the winstone tracker too: > https://sourceforge.net/tracker/?func=detail&aid=3308285&group_id=98922&atid=622497 > Workaround: Use Tomcat, not embedded winstone (that's what I'm doing now). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13274) French translation for users is incorrect: "Utlisateurs" instead of "Utilisateurs"
Olivier Truong created JENKINS-13274: Summary: French translation for users is incorrect: "Utlisateurs" instead of "Utilisateurs" Key: JENKINS-13274 URL: https://issues.jenkins-ci.org/browse/JENKINS-13274 Project: Jenkins Issue Type: Bug Components: other Affects Versions: current Reporter: Olivier Truong Priority: Trivial The french translation in menu for "users" is "Utlisateurs". The correct spelling is "Utilisateurs" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13273) cannot run Jenkins as a Windows Service on a Windows 7
Olivier Bagnack created JENKINS-13273: - Summary: cannot run Jenkins as a Windows Service on a Windows 7 Key: JENKINS-13273 URL: https://issues.jenkins-ci.org/browse/JENKINS-13273 Project: Jenkins Issue Type: Bug Components: lastsuccessversioncolumn Affects Versions: current Environment: Windows 7 Reporter: Olivier Bagnack I'm trying to get startet with Jenkins and cannot run Jenkins as a Windows Service on a Windows 7 System. I've downloaded the latest jenkins.war and run the "java -jar jenkins.war" on the command prompt. While loading the dependencies, Jenkins has thrown following warning: "WARNING: Non-XML-Schema-compliant parser detected. Servlet spec <= 2.3 supported" However I ran "http://localhost:8080"; on Firefox 11 and the an 500 error code came out with the following stack trace: java.lang.NoSuchMethodError: org.dom4j.io.OutputFormat.setXHTML(Z)V at org.kohsuke.stapler.jelly.HTMLWriterOutput.createFormat(HTMLWriterOutput.java:56) at org.kohsuke.stapler.jelly.HTMLWriterOutput.create(HTMLWriterOutput.java:45) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.createXMLOutput(DefaultScriptInvoker.java:68) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:51) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:560) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:622) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:485) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) 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.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.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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) A part from java is there any prerequisites I need to get Jenkins properly run on a windows 7 system. Thx for your suggestions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160958#comment-160958 ] Uwe Stuehler edited comment on JENKINS-9882 at 3/29/12 3:09 PM: It seems to me that this bug might not have been solved completely, or it is a different but similar issue we're seeing. After about a day of normal operation, we see connections via HTTP and AJP being accept()ed and that the thread which is accepting these connections is then going back to poll()... And then _nothing_ happens with the new connection, not a single read() or anything. New threads aren't created either. We're at exactly 200 "RequestHandlerThread" threads in state RUNNABLE. Is 200 a fixed limit on the number of request handler threads? *Edit*: added stack trace All RequestHandlerThread threads have this exact same backtrace: {noformat} "RequestHandlerThread[#871]" daemon prio=10 tid=0x7fee8527a800 nid=0xf2c runnable [0x7fee7d493000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.DataInputStream.readFully(DataInputStream.java:178) at java.io.DataInputStream.readFully(DataInputStream.java:152) at winstone.ajp13.Ajp13IncomingPacket.(Ajp13IncomingPacket.java:60) at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:170) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:67) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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) {noformat} was (Author: ustuehler): It seems to me that this bug might not have been solved completely, or it is a different but similar issue we're seeing. After about a day of normal operation, we see connections via HTTP and AJP being accept()ed and that the thread which is accepting these connections is then going back to poll()... And then _nothing_ happens with the new connection, not a single read() or anything. New threads aren't created either. We're at exactly 200 "RequestHandlerThread" threads in state RUNNABLE. Is 200 a fixed limit on the number of request handler threads? *Edit*: added stack trace {noformat} "RequestHandlerThread[#871]" daemon prio=10 tid=0x7fee8527a800 nid=0xf2c runnable [0x7fee7d493000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.DataInputStream.readFully(DataInputStream.java:178) at java.io.DataInputStream.readFully(DataInputStream.java:152) at winstone.ajp13.Ajp13IncomingPacket.(Ajp13IncomingPacket.java:60) at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:170) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:67) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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) {noformat} > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting fo
[JIRA] (JENKINS-12632) Subversion plugin update fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160959#comment-160959 ] Jeremy Zerr commented on JENKINS-12632: --- I can confirm the exact same thing happening on Jenkins 1.457 under RHEL 5.6 when I use the steps above in the previous comment from Paul. 1.34 is the current Subversion version, 1.39 is the one listed as latest. I can also confirm that pinning the 1.39 JPI after the download, as Paul did, does in fact work for me too. Thanks, Jeremy Zerr > Subversion plugin update fails > -- > > Key: JENKINS-12632 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12632 > Project: Jenkins > Issue Type: Bug > Components: cvs, plugin, subversion, update-center > Environment: Jenkins 1.450 > CentOS 6.2 (2.6.32-220.4.1.el6.centos.plus.x86_64) > java version "1.6.0_29" > Java(TM) SE Runtime Environment (build 1.6.0_29-b11) > Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) >Reporter: Paul Milliken > Labels: jenkins, plugin > > I'm encountering an issue similar to JENKINS-12514 with Jenkins 1.450. > Update manager reports that I'm running subversion plugin 1.34 and 1.37 is > available. In my plugins folder I can see: > -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak > -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi > I tell Jenkins to install 1.37. Once it's downloaded I can see: > -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak > -rw-rw-r--. 1 jenkins jenkins 2103308 Feb 2 15:43 subversion.jpi > Checking the manifests: > [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep > Plugin-Version > Plugin-Version: 1.34 > [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep > Plugin-Version > Plugin-Version: 1.37 > Restart jenkins to apply the changes. At this point, the present files are: > -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak > -rw-rw-r--. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi > and the manifests: > [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep > Plugin-Version > Plugin-Version: 1.34 > [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep > Plugin-Version > Plugin-Version: 1.34 > And update manager still reports 1.34 with 1.37 available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160958#comment-160958 ] Uwe Stuehler edited comment on JENKINS-9882 at 3/29/12 3:09 PM: It seems to me that this bug might not have been solved completely, or it is a different but similar issue we're seeing. After about a day of normal operation, we see connections via HTTP and AJP being accept()ed and that the thread which is accepting these connections is then going back to poll()... And then _nothing_ happens with the new connection, not a single read() or anything. New threads aren't created either. We're at exactly 200 "RequestHandlerThread" threads in state RUNNABLE. Is 200 a fixed limit on the number of request handler threads? *Edit*: added stack trace {noformat} "RequestHandlerThread[#871]" daemon prio=10 tid=0x7fee8527a800 nid=0xf2c runnable [0x7fee7d493000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.DataInputStream.readFully(DataInputStream.java:178) at java.io.DataInputStream.readFully(DataInputStream.java:152) at winstone.ajp13.Ajp13IncomingPacket.(Ajp13IncomingPacket.java:60) at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:170) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:67) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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) {noformat} was (Author: ustuehler): It seems to me that this bug might not have been solved completely, or it is a different but similar issue we're seeing. After about a day of normal operation, we see connections via HTTP and AJP being accept()ed and that the thread which is accepting these connections is then going back to poll()... And then _nothing_ happens with the new connection, not a single read() or anything. New threads aren't created either. We're at exactly 200 "RequestHandlerThread" threads in state RUNNABLE. Is 200 a fixed limit on the number of request handler threads? > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting for retry > and a bit later (this starts repeating): > [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no > more request handlers available in the pool > [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no > more request handlers available in the pool > Jenkins then stops handling requests successfully - at the beginning > intermittently, but finally basically failing almost all of the > requests. > Using VisualVM I can see that there is a thousand RequestHandlerThread > threads in wait state, and that over 1200 file descriptors are > currently in use. > I think the requests start failing because winstone has a this limit: > private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; > as it doesn't seem to be running out of available fds (apparently 8192 > is the maximum in this setup). > When I restart jenkins I can verify a slow buildup of threads and used > file descriptors: > * 10 minutes after restart: 136 live threads, 256 fds used > * 20 minutes: 150 threads, 271 fds > * 30 minutes: 161 threads, 280 fds > * 110 minutes: 255 threads, 376 fds > I've loo
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160958#comment-160958 ] Uwe Stuehler commented on JENKINS-9882: --- It seems to me that this bug might not have been solved completely, or it is a different but similar issue we're seeing. After about a day of normal operation, we see connections via HTTP and AJP being accept()ed and that the thread which is accepting these connections is then going back to poll()... And then _nothing_ happens with the new connection, not a single read() or anything. New threads aren't created either. We're at exactly 200 "RequestHandlerThread" threads in state RUNNABLE. Is 200 a fixed limit on the number of request handler threads? > Jenkins runs out of file descriptors (winstone problem) > --- > > Key: JENKINS-9882 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT >Reporter: Santeri Paavolainen > > Running Jenkins with the embedded Winstone server for a long time > under constant load conditions causes file descriptor and thread > leakage. > Environment: Debian 5, sun-java-jdk (1.6.0_22) > Jenkins version: 1.414-SNAPSHOT > What happens: > After running for about 1 day the following appears on jenkins log > file: > [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded > - waiting for retry > and a bit later (this starts repeating): > [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no > more request handlers available in the pool > [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded > - waiting for retry > [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no > more request handlers available in the pool > Jenkins then stops handling requests successfully - at the beginning > intermittently, but finally basically failing almost all of the > requests. > Using VisualVM I can see that there is a thousand RequestHandlerThread > threads in wait state, and that over 1200 file descriptors are > currently in use. > I think the requests start failing because winstone has a this limit: > private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; > as it doesn't seem to be running out of available fds (apparently 8192 > is the maximum in this setup). > When I restart jenkins I can verify a slow buildup of threads and used > file descriptors: > * 10 minutes after restart: 136 live threads, 256 fds used > * 20 minutes: 150 threads, 271 fds > * 30 minutes: 161 threads, 280 fds > * 110 minutes: 255 threads, 376 fds > I've looked at the repository version of winstone, and looking at the > code there seems to be a race condition in handling of the request > handler pool. > When a request is received by ObjectPool.handleRequest, it looks for > an available request handler from unusedRequestHandlerThreads and > calls commenceRequestHandling on the available thread. > commenceRequestHandling in turn does this.notifyAll() to wake up the > thread. So far so good. However when the thread has finished > processing the request, it calls > this.objectPool.releaseRequestHandler(this) and *then* waits. I think > here's a race condition, since what can happen is that object pool > called (CALL) and request handler thread (RH) can interleave like > this: > # RH (in RequestHandler.run): this.objectPool.releaseRequestHandler(this) > # RH (in ObjectPool.releaseRequestHandler): > this.unusedRequestHandlerThreads.add(rh) > # CALL (in ObjectPool.handleRequest): take RH from unusedRequestHandlerThreads > # CALL (in ObjectPool.handleRequest): rh.commenceRequestHandling(socket, > listener); > # CALL (in RequestHandler.commenceRequestHandling): this.notifyAll() > # RH (in ObjectPool.run): this.wait() > Since notify is lost (no waiters), this.wait() in the last step will > hang forever. This will leak a file descriptor since the socket given > to be processed is never reclaimed, and threads are effectively lost > as Winstone will then create more RequestHandlers. > Now, this is of course a winstone problem, but its development seems > to be d-e-a-d at least looking at its bug tracker. As long as this > problem affect Jenkins, I'd still classify it as a Jenkins problem too. > I've put this into the winstone tracker too: > https://sourceforge.net/tracker/?func=detail&aid=3308285&group_id=98922&atid=622497 > Workaround: Use Tomcat, not embedded winstone (that's what I'm doing now). -- This message is automatically generated by JIRA. If you
[JIRA] (JENKINS-13272) "Build History" view for a node: missing build time information
chanti vlad created JENKINS-13272: - Summary: "Build History" view for a node: missing build time information Key: JENKINS-13272 URL: https://issues.jenkins-ci.org/browse/JENKINS-13272 Project: Jenkins Issue Type: Improvement Components: core Affects Versions: current Reporter: chanti vlad Priority: Minor Hi, i am talking about the "Build History" page of a Jenkins node, i.e. http://your_jenkins/computer/your_node/builds In Jenkins 1.457, there are 4 columns to be seen: "Build", "Time since", "Status" and an icon with the link to the console output. I wish there would also be a "Build time" column, so that we have the information of how long the builds take on a given host/node. Is there a rationale why this is currently not the case? This would be a very simple fix in: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/hudson/buildListTable.jelly at the line 47. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13200) 1.455: Block build when downstream project is building doesn't work
[ https://issues.jenkins-ci.org/browse/JENKINS-13200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160957#comment-160957 ] Kay Abendroth commented on JENKINS-13200: - I will try to reproduce the error. > 1.455: Block build when downstream project is building doesn't work > --- > > Key: JENKINS-13200 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13200 > Project: Jenkins > Issue Type: Bug > Components: build-pipeline > Environment: Jenkins 1.455, CentOS 5.5 >Reporter: Kay Abendroth >Priority: Blocker > Labels: build > > We have a test job chain that runs on a single slave. As this chain can be > triggered serveral times during the day it's very important that it is > blocked from running on that slave, if a downstream job is building. That > doesn't work anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13260) Can't hide advanced configuration
[ https://issues.jenkins-ci.org/browse/JENKINS-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Bevers updated JENKINS-13260: - Issue Type: Improvement (was: Bug) Assignee: (was: Tom Bevers) Priority: Minor (was: Blocker) Due Date: (was: 2/Apr/12) > Can't hide advanced configuration > - > > Key: JENKINS-13260 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13260 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: Tom Bevers >Priority: Minor > > After clicking on the advanced button in the configuration form, you can't > hide the advanced configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13200) 1.455: Block build when downstream project is building doesn't work
[ https://issues.jenkins-ci.org/browse/JENKINS-13200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160956#comment-160956 ] Kay Abendroth commented on JENKINS-13200: - [dty|https://github.com/dty]: {quote} I don't think this is the correct fix. isBuilding() will return always return true if isLogUpdated() returns true. Adding a condition for isBuilding() would actually allow builds in the POST_PRODUCTION state to be considered not blocking, which was what I fixed with my checkin. {quote} --- [1] https://github.com/jenkinsci/jenkins/pull/414#issuecomment-4710598 > 1.455: Block build when downstream project is building doesn't work > --- > > Key: JENKINS-13200 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13200 > Project: Jenkins > Issue Type: Bug > Components: build-pipeline > Environment: Jenkins 1.455, CentOS 5.5 >Reporter: Kay Abendroth >Priority: Blocker > Labels: build > > We have a test job chain that runs on a single slave. As this chain can be > triggered serveral times during the day it's very important that it is > blocked from running on that slave, if a downstream job is building. That > doesn't work anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12467) jabber plugin not connecting after update jabber
[ https://issues.jenkins-ci.org/browse/JENKINS-12467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kutzi resolved JENKINS-12467. - Resolution: Cannot Reproduce > jabber plugin not connecting after update jabber > > > Key: JENKINS-12467 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12467 > Project: Jenkins > Issue Type: Bug > Components: jabber >Reporter: Pat Hoyt >Assignee: kutzi >Priority: Minor > Labels: jabber > Attachments: jabberProblem.txt > > > After updating jabber plugin to 1.22 (not sure what version it was at > before), no longer works. Console output for a job: Jabber notifier plugin: > [ERROR] not connected. Cannot send message to > Output from the jabber logger is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13259) Convert forms to use twitter bootstrap styling
[ https://issues.jenkins-ci.org/browse/JENKINS-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160955#comment-160955 ] Tom Bevers commented on JENKINS-13259: -- Can you create for each todo an issue? We can use jQuery, so that's no problem. About the hetero-list and section navigation where do you want to implement it? > Convert forms to use twitter bootstrap styling > -- > > Key: JENKINS-13259 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13259 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: Tom Bevers >Assignee: Tom Bevers > > Change all forms to use twitter bootstrap styling -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13271) Perforce plugin throws null pointer exception upon encountering deleted user
S Stack created JENKINS-13271: - Summary: Perforce plugin throws null pointer exception upon encountering deleted user Key: JENKINS-13271 URL: https://issues.jenkins-ci.org/browse/JENKINS-13271 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: Jenkins 1.457 P4 Plugin 1.3.11 Reporter: S Stack Assignee: Rob Petti Priority: Blocker P4 plugin throws a null pointer exception causing job failure when running a "p4 -s users " where is a once active, now deleted account. The only workaround appears to be to recreate the deleted account which consumes a Perforce license. I have verified this workaround twice with two different deleted accounts. Example failure output: Started by user cmteam Building in workspace /var/opt/jenkins-data/jobs/some-deploy/workspace Using master perforce client: ciqa-some-deploy [workspace] $ p4 workspace -o ciqa-some-deploy Saving modified client ciqa-some-deploy [workspace] $ p4 -s client -i Clearing workspace... Note: .repository directory in workspace (if exists) is skipped. Cleared workspace. Last build changeset: 79972 [workspace] $ p4 -s changes -s submitted -m 1 //ciqa-some-deploy/...@somelabel-4.1.0.0 [workspace] $ p4 -s changes -s submitted //ciqa-some-deploy/...@79973,@85075 [workspace] $ p4 describe -s 85075 [workspace] $ p4 -G where //... [workspace] $ p4 describe -s 85012 [workspace] $ p4 describe -s 85005 [workspace] $ p4 describe -s 84668 [workspace] $ p4 describe -s 81052 [workspace] $ p4 describe -s 81031 [workspace] $ p4 describe -s 81029 [workspace] $ p4 -s users valid-user-1 [workspace] $ p4 user -o valid-user-1 [workspace] $ p4 -s users valid-user-2 [workspace] $ p4 user -o valid-user-2 [workspace] $ p4 -s users deleted-user FATAL: null java.lang.NullPointerException at hudson.plugins.perforce.PerforceSCM.retrieveUserInformation(PerforceSCM.java:633) at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:816) at hudson.model.AbstractProject.checkout(AbstractProject.java:1197) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) at hudson.model.Run.run(Run.java:1410) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) And of course the job fails at this point. Note that "p4 -s users deleted-user" returns error: deleted-user - no such user(s). exit: 0 while "p4 -s users valid-user" returns info: valid-user (Valid User) accessed 2012/03/29 exit: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12704) WORKSPACE variable for concurrent builds are not defined properly.
[ https://issues.jenkins-ci.org/browse/JENKINS-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160954#comment-160954 ] Sergey Smirnov commented on JENKINS-12704: -- Jenkins ver. 1.457 Environment Injector Plugin 1.44 WORKSPACE works correct with concurent builds > WORKSPACE variable for concurrent builds are not defined properly. > -- > > Key: JENKINS-12704 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12704 > Project: Jenkins > Issue Type: Bug > Components: concurrent-build, envinject > Environment: redhat (master/slave) > jenkins ver=1.448 >Reporter: Natalia Naumova >Assignee: gbois > > I have master/slave setup, and my project has the ability to execute builds > in parallel, i.e. I have 'Execute concurrent builds if necessary' option > turned on. > But when I'm trying to inject any environment variables into my job ( 'Inject > environment variables to the build process' option ), then the $WORKSPACE > variable is NOT defined properly for parallel builds. > They should be > > ${JENKINS_HOME/workspace/${JOB_NAME} > ${JENKINS_HOME/workspace/${JOB_NAME}@2 > ${JENKINS_HOME/workspace/${JOB_NAME}@3 > ... > But $WORKSPACE always points to > > ${JENKINS_HOME/workspace/${JOB_NAME} > for all job runs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13149) SCM Poll causing non-stop builds
[ https://issues.jenkins-ci.org/browse/JENKINS-13149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160953#comment-160953 ] Olivier Trempe commented on JENKINS-13149: -- Same thing on my side. Maybe this info can help: The polled repo contains a sub-repo in which there are large files (files tagged with --large mercurial extension) > SCM Poll causing non-stop builds > > > Key: JENKINS-13149 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13149 > Project: Jenkins > Issue Type: Bug > Components: mercurial >Affects Versions: current > Environment: HG 2.0.1 / Jenkins 1.456 / Plugin 1.3.8 >Reporter: Justin Rovang >Assignee: Kohsuke Kawaguchi >Priority: Critical > > I hate to bring such conflicting information into a bug report but I'm at a > loss on this! > This only happens for this one repo - I've deleted and re-created it, and > setup from scratch with no joy. > HG SCM Poll log insists it's finding changes and is firing a build off of > 'Dependent changes detected'. > Started on Mar 19, 2012 11:00:24 PM > [src] $ hg pull --rev default > pulling from /var/hg/repos/mpl > no changes found > [src] $ hg log --style > /var/lib/jenkins/jobs/mpl/workspace/tmp2857899180971434423style --branch > default --no-merges --prune 9c80c470fa3ef8d89c2352c08babb3f466b9aa24 > id:5b02d29a94c43648da2eb0a16f12c2e42eb46c87 > files:build.xml: > Dependent changes detected > Done. Took 0.21 sec > Changes found > There's no open/un-merged heads in the repo either: > default 141:9c80c470fa3e > If I downgrade to 1.3.7, it works fine (seems to run a different technique) > HG SCM Poll log from 1.3.7: > Started on Mar 19, 2012 11:11:14 PM > [src] $ hg incoming --style > /var/lib/jenkins/jobs/mpl/workspace/tmp1826463261407545325style --no-merges > --rev default --newest-first > comparing with /var/hg/repos/mpl > no changes found > Done. Took 53 ms > No changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13270) Occasional login failures using p4 ticket
lestin created JENKINS-13270: Summary: Occasional login failures using p4 ticket Key: JENKINS-13270 URL: https://issues.jenkins-ci.org/browse/JENKINS-13270 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: 1.456 Jenkins with latest perforce plugin Reporter: lestin Priority: Minor Saw the following log whilst nothing has changed during the period: INFO: job_name_here #4437 main build action completed: SUCCESS Mar 27, 2012 6:11:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 6:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 6:31:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 6:41:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 6:51:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 7:01:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 7:01:18 AM hudson.model.Run run INFO: job_name_here #4438 main build action completed: SUCCESS Mar 27, 2012 7:11:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 7:21:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 7:31:10 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Login with '/tools/perforce/2010.1/bin.linux26x86/p4' failed: Login attempt failed: Password invalid. Mar 27, 2012 7:43:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Attempt to workaround p4 executable location failed com.tek42.perforce.PerforceException: Could not run perforce command. at hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:88) at com.tek42.perforce.parse.AbstractPerforceTemplate.p4Login(AbstractPerforceTemplate.java:596) at com.tek42.perforce.parse.AbstractPerforceTemplate.login(AbstractPerforceTemplate.java:566) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:372) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61) at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1325) at hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1019) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) at hudson.scm.SCM.poll(SCM.java:373) at hudson.model.AbstractProject.poll(AbstractProject.java:1340) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 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:619) Caused by: java.io.IOException: Cannot run program "/usr/bin/p4" (in directory "/projects/jenkins/jenkins_home"): java.io.IOException: error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at hudson.Proc$LocalProc.(Proc.java:244) at hudson.Proc$LocalProc.(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:707) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.plugins.perforce.HudsonP4DefaultExecutor.exec(HudsonP4DefaultExecutor.java:79) ... 19 more Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:453) ... 24 more Problem: Login attempt failed: Password invalid. Mar 27, 2012 7:51:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate login WARNING: Using p4 issued ticket. Mar 27, 2012 8:01:09 AM com.tek42.perforce.parse.AbstractPerforceTemplate l
[JIRA] (JENKINS-12467) jabber plugin not connecting after update jabber
[ https://issues.jenkins-ci.org/browse/JENKINS-12467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160952#comment-160952 ] Pat Hoyt commented on JENKINS-12467: Jabber notification is now working after Jenkins upgraded to 1.457 > jabber plugin not connecting after update jabber > > > Key: JENKINS-12467 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12467 > Project: Jenkins > Issue Type: Bug > Components: jabber >Reporter: Pat Hoyt >Assignee: kutzi >Priority: Minor > Labels: jabber > Attachments: jabberProblem.txt > > > After updating jabber plugin to 1.22 (not sure what version it was at > before), no longer works. Console output for a job: Jabber notifier plugin: > [ERROR] not connected. Cannot send message to > Output from the jabber logger is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13269) Unable to connect to LDAP server
Matthias Kraft created JENKINS-13269: Summary: Unable to connect to LDAP server Key: JENKINS-13269 URL: https://issues.jenkins-ci.org/browse/JENKINS-13269 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: openSUSE 11.4 x86_64, Jenkins 1.457, java.runtime.name=Java(TM) SE Runtime Environment, java.runtime.version=1.6.0_31-b04 Reporter: Matthias Kraft Priority: Critical After switching from 1.456 to 1.457 Jenkins was no longer able to communicate with the LDAP server for authentication. Switching back to 1.456 resolved the issue. Error message and stack trace: Unable to connect to XXLDAPserverXX:3268 : javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 775, vece] javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 775, vece] at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3067) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2815) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2729) at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:296) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.(InitialContext.java:197) at javax.naming.directory.InitialDirContext.(InitialDirContext.java:82) at hudson.security.LDAPSecurityRealm$DescriptorImpl.doServerCheck(LDAPSecurityRealm.java:575) 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.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656) 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:571) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:485) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) 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:74) 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.
[JIRA] (JENKINS-12514) .hpi versus .jpi causes inability to upgrade Subversion Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160951#comment-160951 ] Bill Michell commented on JENKINS-12514: The issue also affects Mac OS X 1.457 > .hpi versus .jpi causes inability to upgrade Subversion Plugin > -- > > Key: JENKINS-12514 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12514 > Project: Jenkins > Issue Type: Bug > Components: update-center > Environment: Ubuntu 11.10, OpenJDK 1.6.0_23, Tomcat 7.0.21, Jenkins > 1.448 & 1.449 > Jenkins 1.456 on Windows Server 2003 64-bit, Sun JDK 6.0.260.3 >Reporter: Charlie Huggard >Assignee: Kohsuke Kawaguchi >Priority: Blocker > > Reproduction: > $JENKINS_HOME/plugins: subversion (directory), subversion.hpi > 1) Open http:///pluginManager. Update Subversion plugin from 1.34 -> > 1.37 using download now and install after restart button. > $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), > subversion.hpi.pinned, subversion.jpi (1.37) > 2) Restart Tomcat/Jenkins > $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), > subversion.hpi (1.34) subversion.hpi.pinned, subversion.jpi (1.37) > 3) PluginManager still reports old version > Should note that the logs report: > INFO: Ignoring /ci/jenkins-home/plugins/subversion.jpi because > /ci/jenkins-home/plugins/subversion.hpi is already loaded > Also the plugin is broken at this point with a NoClassDefFound on > org/tmatesoft/svn/core/SVNException > Clean State: > 1) /etc/init.d/tomcat7 stop > 2) cd $JENKINS_HOME/plugins > 3) rm subversion* > 4) /etc/init.d/tomcat7 start > Workaround: > 1) Restore clean state > 2) Update plugin > 3) Stop tomcat/jenkins > 4) cd $JENKINS_HOME/plugins > 5) mv subversion.jpi subversion.hpi > 6) Start tomcat/jenkins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12821) android.device
[ https://issues.jenkins-ci.org/browse/JENKINS-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160950#comment-160950 ] Richard Mortimer commented on JENKINS-12821: No I didn't get around to filing it. With the new SDK being out I figure I ought to test against that before reporting it now. > android.device > --- > > Key: JENKINS-12821 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12821 > Project: Jenkins > Issue Type: Bug > Components: android-emulator >Affects Versions: current >Reporter: Sebastian Schefczyk >Assignee: Richard Mortimer >Priority: Minor > > The following configuration of the android-maven-plugin will not find the > running emulator on Jenkins. > Commenting this line will find the emulator. > On my local machine this is working fine, but not in Jenkins. > Both machines use maven 3.0.4 on Linux/Ubuntu. > com.jayway.maven.plugins.android.generation2 > android-maven-plugin > >... > emulator >... > > > This configuration is useful on the local machine, if you are developing > while charging your phone via USB. > Best regards, that's a really nice plugin! > Sebl29 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12250) Critical block can not be added into conditional step
[ https://issues.jenkins-ci.org/browse/JENKINS-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160949#comment-160949 ] Oleksandr Popov commented on JENKINS-12250: --- Hello? > Critical block can not be added into conditional step > - > > Key: JENKINS-12250 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12250 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep, exclusion > Environment: Jenkins 1.445 > Jenkins Exclusion Plug-in 0.6 > conditional-buildstep 0.2 >Reporter: Oleksandr Popov >Assignee: Anthony Roux >Priority: Critical > Attachments: critical-block.PNG > > > I'm not able to add critical block into conditional step. See screen-shot for > details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mwebber updated JENKINS-12994: -- Priority: Critical (was: Major) Bumping priority from Major to Critical, as this problem is adversely affecting a lot of people. > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo >Priority: Critical > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160947#comment-160947 ] Waldek M commented on JENKINS-12994: Same here. In case of many scheduled builds, this may cause them never to happen. > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160946#comment-160946 ] Krzysztof Malinowski commented on JENKINS-12994: Same issue here. All builds are blocked until all quiet periods end. This is a serious disadvantage and I would like to vote for fixing this in the first place. > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13268) Build hang
Coding Nerd created JENKINS-13268: - Summary: Build hang Key: JENKINS-13268 URL: https://issues.jenkins-ci.org/browse/JENKINS-13268 Project: Jenkins Issue Type: Bug Components: buildresult-trigger Affects Versions: current Reporter: Coding Nerd Attachments: Threadump.txt I configure Jenkins to auto-install Ant 1.8.3 then execute the build. The build hang after installing ant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13267) Wrong working dir used on Windows if executed command is in a subfolder
[ https://issues.jenkins-ci.org/browse/JENKINS-13267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Skupin updated JENKINS-13267: Summary: Wrong working dir used on Windows if executed command is in a subfolder (was: Wrong workspace used on Windows if executed command is in a subfolder) > Wrong working dir used on Windows if executed command is in a subfolder > --- > > Key: JENKINS-13267 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13267 > Project: Jenkins > Issue Type: Bug > Components: xshell >Affects Versions: current > Environment: Any Windows platform >Reporter: Henrik Skupin > > If a build step with XShell calls a command which is not in the current > working dir but in a sub folder, the sub folder is used as current working > dir. This issue only persists on Windows and cannot be seen on Linux or Mac. > Just take a command (which is a wrapper script) like: > scripts/run hg clone https://hg.mozilla.org/qa/mozmill-automation > It should clone the given repository into the nodes working dir, but right > now it will end up as 'scripts/mozmill-automation'. So the wrapper scripts > working dir is used. > Calling the wrapper script from outside Jenkins it works fine, so it has to > be a XShell bug. > As reference of a problematic job see: > https://github.com/whimboo/mozmill-ci/blob/master/jenkins-master/jobs/functional-test/config.xml#L78 > Steps to reproduce: > 1. Clone https://github.com/whimboo/mozmill-ci/ > 2. Follow the readme and setup the system > 3. Add a node for Windows > 4. Run 'Build Now' on the functional testrun (Branch: mozilla-central, > Platform: win32, Locale: en-US, BuildId: 20120328115525, Nodes: win_xp, > Env-Platform: Windows) > 5. Check the working dir of the project and notice that the hg clone is not > ending up in the root working dir > There is also no difference with executeFromWorkingDir enabled or disabled. > 5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13267) Wrong workspace used on Windows if executed command is in a subfolder
Henrik Skupin created JENKINS-13267: --- Summary: Wrong workspace used on Windows if executed command is in a subfolder Key: JENKINS-13267 URL: https://issues.jenkins-ci.org/browse/JENKINS-13267 Project: Jenkins Issue Type: Bug Components: xshell Affects Versions: current Environment: Any Windows platform Reporter: Henrik Skupin If a build step with XShell calls a command which is not in the current working dir but in a sub folder, the sub folder is used as current working dir. This issue only persists on Windows and cannot be seen on Linux or Mac. Just take a command (which is a wrapper script) like: scripts/run hg clone https://hg.mozilla.org/qa/mozmill-automation It should clone the given repository into the nodes working dir, but right now it will end up as 'scripts/mozmill-automation'. So the wrapper scripts working dir is used. Calling the wrapper script from outside Jenkins it works fine, so it has to be a XShell bug. As reference of a problematic job see: https://github.com/whimboo/mozmill-ci/blob/master/jenkins-master/jobs/functional-test/config.xml#L78 Steps to reproduce: 1. Clone https://github.com/whimboo/mozmill-ci/ 2. Follow the readme and setup the system 3. Add a node for Windows 4. Run 'Build Now' on the functional testrun (Branch: mozilla-central, Platform: win32, Locale: en-US, BuildId: 20120328115525, Nodes: win_xp, Env-Platform: Windows) 5. Check the working dir of the project and notice that the hg clone is not ending up in the root working dir There is also no difference with executeFromWorkingDir enabled or disabled. 5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13244) Improve logic for shell script completion
[ https://issues.jenkins-ci.org/browse/JENKINS-13244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Skupin resolved JENKINS-13244. - Resolution: Not A Defect I think that we can close this one. It's working fine now on Windows even when the script has a .cmd extension. Also for Linux is safer to not have a .sh extension and simply use the basename. > Improve logic for shell script completion > - > > Key: JENKINS-13244 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13244 > Project: Jenkins > Issue Type: Bug > Components: xshell >Affects Versions: current > Environment: This issue applies to all platforms >Reporter: Henrik Skupin > > Currently you can specify a script to call by simply removing the extension > and XShell will automatically add .cmd on Windows. Not sure why .sh is not > getting added on Linux because it should be mostly the default extension for > bash scripts. > Also would it be possible to not only add the default extension but also > check for alternatives? Batch files on Windows have a .cmd extension > nowadays, and not sure what options exist on Linux. So would be great if the > plugin could support multiple extensions, select the best match or fails when > executing the shell if multiple matches exist which can't be resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13224) JobConfigHistory not visible to Roles who have the right to configure Jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-13224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160944#comment-160944 ] Igor Masen commented on JENKINS-13224: -- Hello Mirko, I tested it now on our productive Environment and there is no bug, sorry for that. I (and my customer) expected the JobConfigHistory Link at the top site as it is if you are logged in as an administrator. That's why we thought it might be a bug. Would it make sense to realize it as a feature? Maybe it's the more "user-friendly"-way to implement this. > JobConfigHistory not visible to Roles who have the right to configure Jobs > -- > > Key: JENKINS-13224 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13224 > Project: Jenkins > Issue Type: Bug > Components: jobconfighistory >Affects Versions: current > Environment: RHEL 6.2 64-Bit, Oracle JDK 1.6.0.30, VMWare TcServer, > Jenkins 1.450, JobConfigHistory Version 1.13 >Reporter: Igor Masen >Assignee: Mirko Friedenhagen > Labels: jobconfighistory > Attachments: screenshot-with-1.424.6.jpg, screenshot_matrix.jpg > > > Hello, > we have a problem on our productive System. We have Matrix-Based Security > activated and People in Roles who have the right to configure build-jobs are > do not see the Button "Job Config History". Please look at the Screenshot > attached. The only Role who is able to see the Button in this environment is > "jenkins_admin". > Kind regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13266) In fluid layout, side-panel may overflow into main-panel
OHTAKE Tomohiro created JENKINS-13266: - Summary: In fluid layout, side-panel may overflow into main-panel Key: JENKINS-13266 URL: https://issues.jenkins-ci.org/browse/JENKINS-13266 Project: Jenkins Issue Type: Bug Components: ui-changes Environment: ui-changes branch Reporter: OHTAKE Tomohiro Attachments: Untitled.png If side-panel contains a wide table, it may overflow into main-panel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13265) Ldap connection failed - jenkins loosing FQDN of ldap server
Joern Muehlencord created JENKINS-13265: --- Summary: Ldap connection failed - jenkins loosing FQDN of ldap server Key: JENKINS-13265 URL: https://issues.jenkins-ci.org/browse/JENKINS-13265 Project: Jenkins Issue Type: Bug Components: active-directory Affects Versions: current Environment: Jenkins in all 1.4xx versions, Linux X86, SLES 10, Apache Tomcat 7.0.14 Reporter: Joern Muehlencord Attachments: exception.txt Jenkins is configured to use LDAP login which works perfectly. After some time - some times directly after restarting tomcat - the login fails. When checking catalina.out the attached exception is thrown. The reason for the failed login is clear - Jenkins is configured to connect to ldap.my.domain - but when this happens Jenkins forgets "ldap" and tries to connect to my.domain only - for sure this does not work as this is no valid host name. To fix this, we need to restart Tomcat until it failes again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160943#comment-160943 ] Michael Clarke commented on JENKINS-13264: -- Could you attached your job's config.xml? > fail checkout 2 modules with different path > --- > > Key: JENKINS-13264 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 > Project: Jenkins > Issue Type: Bug > Components: cvs > Environment: linux >Reporter: Eric Co > > I create two cvs modules with the path > lib/flac-1.2.1 > drv/linux/fuse > when it check out, got the error: > cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 > lib/flac-1.2.1 > cvs [checkout aborted]: could not change directory to requested checkout > directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira