date:20120329

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

2012-03-29 Thread uday.yat...@gmail.com (JIRA)

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

2012-03-29 Thread pixma...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread oldel...@java.net (JIRA)


[ 
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

2012-03-29 Thread gb...@java.net (JIRA)


[ 
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

2012-03-29 Thread b...@ghs.com (JIRA)

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

2012-03-29 Thread irist...@java.net (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 ...

2012-03-29 Thread mweb...@java.net (JIRA)


 [ 
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 ...

2012-03-29 Thread cron...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread guillaume.bilod...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread ullrich.haf...@gmail.com (JIRA)


 [ 
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

2012-03-29 Thread martin.sche...@gcsc.uni-frankfurt.de (JIRA)


 [ 
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

2012-03-29 Thread ullrich.haf...@gmail.com (JIRA)

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

2012-03-29 Thread cwer...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread dorin.mari...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread susan.st...@theice.com (JIRA)


[ 
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'."

2012-03-29 Thread ch...@orr.me.uk (JIRA)


 [ 
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

2012-03-29 Thread jfr...@java.net (JIRA)


[ 
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

2012-03-29 Thread wba...@java.net (JIRA)


[ 
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

2012-03-29 Thread jfr...@java.net (JIRA)

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'."

2012-03-29 Thread billmag...@gmail.com (JIRA)

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

2012-03-29 Thread m...@cebe.cc (JIRA)


[ 
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

2012-03-29 Thread jenkinsj...@koant.com (JIRA)


[ 
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

2012-03-29 Thread m...@cebe.cc (JIRA)


[ 
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

2012-03-29 Thread m...@cebe.cc (JIRA)


[ 
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

2012-03-29 Thread torresszd...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread pixma...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread cof...@gmail.com (JIRA)


[ 
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)

2012-03-29 Thread y...@schli.ch (JIRA)


[ 
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"

2012-03-29 Thread oliv.tru...@gmail.com (JIRA)

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

2012-03-29 Thread ba...@ymail.com (JIRA)

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

2012-03-29 Thread jer...@zerrtech.com (JIRA)


[ 
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

2012-03-29 Thread chantiv...@yahoo.fr (JIRA)

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

2012-03-29 Thread kay.abendr...@epages.com (JIRA)


[ 
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

2012-03-29 Thread t.bev...@gmail.com (JIRA)


 [ 
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

2012-03-29 Thread kay.abendr...@epages.com (JIRA)


[ 
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

2012-03-29 Thread ku...@gmx.de (JIRA)


 [ 
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

2012-03-29 Thread t.bev...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread susan.st...@theice.com (JIRA)

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.

2012-03-29 Thread svs1...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread oliviertre...@hotmail.com (JIRA)


[ 
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

2012-03-29 Thread les...@java.net (JIRA)

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

2012-03-29 Thread h...@satlantic.com (JIRA)


[ 
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

2012-03-29 Thread matthias.kr...@softwareag.com (JIRA)

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

2012-03-29 Thread bill.mich...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread oldel...@java.net (JIRA)


[ 
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

2012-03-29 Thread pxan...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread mweb...@java.net (JIRA)


 [ 
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

2012-03-29 Thread w.male...@gmail.com (JIRA)


[ 
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

2012-03-29 Thread ra...@java.net (JIRA)


[ 
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

2012-03-29 Thread binh.leth...@gmail.com (JIRA)

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

2012-03-29 Thread hsku...@gmail.com (JIRA)


 [ 
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

2012-03-29 Thread hsku...@gmail.com (JIRA)

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

2012-03-29 Thread hsku...@gmail.com (JIRA)


 [ 
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

2012-03-29 Thread igor.ma...@googlemail.com (JIRA)


[ 
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