[JIRA] (JENKINS-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162134#comment-162134
 ] 

SCM/JIRA link daemon commented on JENKINS-13491:


Code changed in jenkins
User: Ulli Hafner
Path:
 src/main/resources/hudson/plugins/tasks/TasksTabDetail/tasks-details.jelly
 src/main/resources/hudson/plugins/tasks/TasksTabDetail/tasks-warnings.jelly
http://jenkins-ci.org/commit/tasks-plugin/240905abea9788469bf8ec2ca7ef657c0ba33cb0
Log:
  [FIXED JENKINS-13491] Center the affected source line in source view.






 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13610) JavaDoc Compiler parser is missing

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162135#comment-162135
 ] 

SCM/JIRA link daemon commented on JENKINS-13610:


Code changed in jenkins
User: Ulli Hafner
Path:
 src/main/java/hudson/plugins/warnings/parser/JavaDocParser.java
 src/test/java/hudson/plugins/warnings/parser/ParserRegistryIntegrationTest.java
http://jenkins-ci.org/commit/warnings-plugin/00fa950f43828b224837f87e10ef698f8fe9c424
Log:
  [FIXED JENKINS-13610] Added missing @Extension to JavaDoc parser.






 JavaDoc Compiler parser is missing
 --

 Key: JENKINS-13610
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13610
 Project: Jenkins
  Issue Type: Bug
  Components: warnings
Affects Versions: current
 Environment: Jenkins v1.458, warnings v4.3
Reporter: Johann Werner
Assignee: Ulli Hafner

 In the recent version of the plugin the JavaDoc Compiler is missing from the 
 parser 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-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162133#comment-162133
 ] 

SCM/JIRA link daemon commented on JENKINS-13491:


Code changed in jenkins
User: Ulli Hafner
Path:
 
plugin/src/main/resources/hudson/plugins/findbugs/FindBugsTabDetail/findbugs-warnings.jelly
http://jenkins-ci.org/commit/findbugs-plugin/e779c1ae1cda48910e33f864a91d0b9934c1a803
Log:
  [FIXED JENKINS-13491] Center the affected source line in source view.






 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13624) When using bitbucket as a code browser, links to changeset are incorrect

2012-04-27 Thread benoit.gue...@gmail.com (JIRA)
benoit guerin created JENKINS-13624:
---

 Summary: When using bitbucket as a code browser, links to 
changeset are incorrect
 Key: JENKINS-13624
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13624
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Reporter: benoit guerin
Assignee: Kohsuke Kawaguchi
Priority: Minor


They are https://bitbucket.org/user/repo/src/changeset/hash/

The good link is https://bitbucket.org/user/repo/changeset/hash/

--
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-13622) ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.

2012-04-27 Thread daniel.peti...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162136#comment-162136
 ] 

Daniel Petisme edited comment on JENKINS-13622 at 4/27/12 7:59 AM:
---

Can you try with IE6 or IE7 please, I'm not sure if ADODB.Stream works with IE8.

  was (Author: danielpetisme):
Can you try with IE6 or IE7 please, I'm not sure if ADODB.Stream works with 
IE8.
e
  
 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 -

 Key: JENKINS-13622
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13622
 Project: Jenkins
  Issue Type: Bug
  Components: qc
Affects Versions: current
 Environment: - Microsoft Windows XP Professional SP 3
 - IE 8  Chrome
 - Jenkins ver. 1.451
 - qc plugin 1.2.1
Reporter: COE CI
Assignee: Daniel Petisme
  Labels: plugin

 +--+
 | Test Name| 
 Status|
 +--+
 | [1]MercuryTours  | 
 Passed|
 +--+
 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 FATAL: Tests report not generated
 Build step 'HP Quality Center' marked build as failure
 Sending e-mails to: 
 Finished: FAILURE

--
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-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread dogf...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162139#comment-162139
 ] 

dogfood commented on JENKINS-13491:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_findbugs #413|http://ci.jenkins-ci.org/job/plugins_findbugs/413/]
 [FIXED JENKINS-13491] Center the affected source line in source view. 
(Revision e779c1ae1cda48910e33f864a91d0b9934c1a803)

 Result = SUCCESS
Ulli Hafner : 
Files : 
* 
plugin/src/main/resources/hudson/plugins/findbugs/FindBugsTabDetail/findbugs-warnings.jelly


 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread dogf...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162138#comment-162138
 ] 

dogfood commented on JENKINS-13491:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_dry 
#344|http://ci.jenkins-ci.org/job/plugins_dry/344/]
 [FIXED JENKINS-13491] Center the affected source line in source view. 
(Revision 7e770464356ff3ee812ba99c8d68b57386fa8591)

 Result = SUCCESS
Ulli Hafner : 
Files : 
* src/main/resources/hudson/plugins/dry/DryTabDetail/dry-warnings.jelly
* src/main/resources/dry/warning.jelly


 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread dogf...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162140#comment-162140
 ] 

dogfood commented on JENKINS-13491:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_tasks 
#347|http://ci.jenkins-ci.org/job/plugins_tasks/347/]
 [FIXED JENKINS-13491] Center the affected source line in source view. 
(Revision 240905abea9788469bf8ec2ca7ef657c0ba33cb0)

 Result = SUCCESS
Ulli Hafner : 
Files : 
* src/main/resources/hudson/plugins/tasks/TasksTabDetail/tasks-details.jelly
* src/main/resources/hudson/plugins/tasks/TasksTabDetail/tasks-warnings.jelly


 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13610) JavaDoc Compiler parser is missing

2012-04-27 Thread dogf...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162141#comment-162141
 ] 

dogfood commented on JENKINS-13610:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! 
[plugins_warnings #399|http://ci.jenkins-ci.org/job/plugins_warnings/399/]
 [FIXED JENKINS-13610] Added missing @Extension to JavaDoc parser. 
(Revision 00fa950f43828b224837f87e10ef698f8fe9c424)

 Result = UNSTABLE
Ulli Hafner : 
Files : 
* 
src/test/java/hudson/plugins/warnings/parser/ParserRegistryIntegrationTest.java
* src/main/java/hudson/plugins/warnings/parser/JavaDocParser.java


 JavaDoc Compiler parser is missing
 --

 Key: JENKINS-13610
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13610
 Project: Jenkins
  Issue Type: Bug
  Components: warnings
Affects Versions: current
 Environment: Jenkins v1.458, warnings v4.3
Reporter: Johann Werner
Assignee: Ulli Hafner

 In the recent version of the plugin the JavaDoc Compiler is missing from the 
 parser 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-13622) ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.

2012-04-27 Thread erna.widianing...@dhl.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162142#comment-162142
 ] 

COE CI commented on JENKINS-13622:
--

oh forgot to mention, i tried also from IE 6 but still same error message,, 

 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 -

 Key: JENKINS-13622
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13622
 Project: Jenkins
  Issue Type: Bug
  Components: qc
Affects Versions: current
 Environment: - Microsoft Windows XP Professional SP 3
 - IE 8  Chrome
 - Jenkins ver. 1.451
 - qc plugin 1.2.1
Reporter: COE CI
Assignee: Daniel Petisme
  Labels: plugin

 +--+
 | Test Name| 
 Status|
 +--+
 | [1]MercuryTours  | 
 Passed|
 +--+
 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 FATAL: Tests report not generated
 Build step 'HP Quality Center' marked build as failure
 Sending e-mails to: 
 Finished: FAILURE

--
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-3922) Slave is slow copying maven artifacts to master

2012-04-27 Thread jimmi.dy...@specsavers.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162143#comment-162143
 ] 

Jimmi Dyson commented on JENKINS-3922:
--

The fix is present, but doesn't actually seem to fix the problem. Rather it 
just improves the speed a bit, but it is still very slow compared to native SSH.

I have done some tests  this seems to be due to the library that Jenkins uses 
for SSH - org.jvnet.hudson:trilead-ssh2:build212-hudson-5. Simple tests show 
really slow SFTPing. I've experimented with [JSch|http://www.jcraft.com/jsch]  
get comparable speeds against native SFTP. I'm working on porting the SSH 
slaves plugin to use JSch (which is released under a BSD-style license - any 
compatibility issues there?).

One drawback of the JSch library is the lack of Putty key support. I don't know 
if this is such a big deal as users can always convert Putty keys to OpenSSH 
format keys using puttygen?

I notice that the org.jvnet.hudson:trilead-ssh2:build212-hudson-5 dependency 
comes as transitive from jenkins-core. Should the SSH library actually be a 
part of core dependencies?

 Slave is slow copying maven artifacts to master
 ---

 Key: JENKINS-3922
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3922
 Project: Jenkins
  Issue Type: Bug
  Components: master-slave
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: John McNair
Assignee: Kohsuke Kawaguchi
Priority: Critical
 Attachments: pom.xml


 The artifact transfer is currently a 3-4x penalty for the project that I am
 working on.  I have reproduced the issue with a simple test pom that does
 nothing but jar hudson.war.  I performed this test on a heterogeneous
 environment.  Both master and slave are running Fedora 10, but the master is a
 faster machine.  Still, it highlights the issue.
 Here are some stats (all stats are after caching dependencies in the local 
 repos):
 Master build through Hudson: 19s
 Master build from command line (no Hudson): 9s
 Slave build through Hudson: 1m46s
 Slave build from command line (no Hudson): 16s
 To be fair we should at least add time to do a straight scp of the artifact 
 from
 slave to master.  The two nodes share a 100 Mbit switch:
 $ scp target/slow-rider-1.0.0-SNAPSHOT.jar master_node:
 slow-rider-1.0.0NAPSHOT.jar  100%   25MB  12.7MB/s   00:02
 Of course this example exaggerates the issue to make it more clear but not by
 too much.  I originally noticed this in a completely separate environment that
 was all virtual.  I reproduced this on two physical machines using a different
 switch and different ethernet drivers (both virtual and physical).  The
 reproducibility plus the comparison against command line + scp leads me to
 suspect eager flushing.

--
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-13625) ERR_CONTENT_DECODING_FAILED returned on testResults and console output after Jenkins reload

2012-04-27 Thread anders.nickel...@gmail.com (JIRA)
Anders Nickelsen created JENKINS-13625:
--

 Summary: ERR_CONTENT_DECODING_FAILED returned on testResults and 
console output after Jenkins reload
 Key: JENKINS-13625
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13625
 Project: Jenkins
  Issue Type: Bug
  Components: core, matrix, swarm
Affects Versions: current
Reporter: Anders Nickelsen
Assignee: Kohsuke Kawaguchi
Priority: Critical


We have matrix configuration job that has a 'slave' axis to distribute tests on 
Jenkins swarm slaves.
When we 'reload configuration from disk' Jenkins all builds in the history of 
the matrix job return ERR_CONTENT_DECODING_FAILED (HTTP error 330) when we 
request console output for any slave on the axis. This also occurs when 
requesting testresults (we record jUnit test results as a part of the build).

We had issues with Jenkins losing references to slave after reload, which were 
solved by https://issues.jenkins-ci.org/browse/JENKINS-8043, and I think this 
bug is related.

When the error occurs the following stack trace is observed in Jenkins' log:
27-Apr-2012 08:26:50 winstone.Logger logInternal
WARNING: Untrapped Error in Servlet
javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: 
jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.461.jar!/hudson/tasks/test/MatrixTestResult/index.jelly:42:60:
 j:forEach java.lang.NullPointerException
at 
org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112)
at 
org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
at 
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
at 
hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java: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.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
 

[JIRA] (JENKINS-3922) Slave is slow copying maven artifacts to master

2012-04-27 Thread jimmi.dy...@specsavers.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmi Dyson reopened JENKINS-3922:
--


The fix slightly speeds it up, but it is still slow enough to extend build 
times considerably with big artifacts. Experimenting with a different SSH 
library that shows good initial signs of speeding things up to near-native SSH 
speed.

 Slave is slow copying maven artifacts to master
 ---

 Key: JENKINS-3922
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3922
 Project: Jenkins
  Issue Type: Bug
  Components: master-slave
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: John McNair
Assignee: Kohsuke Kawaguchi
Priority: Critical
 Attachments: pom.xml


 The artifact transfer is currently a 3-4x penalty for the project that I am
 working on.  I have reproduced the issue with a simple test pom that does
 nothing but jar hudson.war.  I performed this test on a heterogeneous
 environment.  Both master and slave are running Fedora 10, but the master is a
 faster machine.  Still, it highlights the issue.
 Here are some stats (all stats are after caching dependencies in the local 
 repos):
 Master build through Hudson: 19s
 Master build from command line (no Hudson): 9s
 Slave build through Hudson: 1m46s
 Slave build from command line (no Hudson): 16s
 To be fair we should at least add time to do a straight scp of the artifact 
 from
 slave to master.  The two nodes share a 100 Mbit switch:
 $ scp target/slow-rider-1.0.0-SNAPSHOT.jar master_node:
 slow-rider-1.0.0NAPSHOT.jar  100%   25MB  12.7MB/s   00:02
 Of course this example exaggerates the issue to make it more clear but not by
 too much.  I originally noticed this in a completely separate environment that
 was all virtual.  I reproduced this on two physical machines using a different
 switch and different ethernet drivers (both virtual and physical).  The
 reproducibility plus the comparison against command line + scp leads me to
 suspect eager flushing.

--
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-13626) Include Source RPMs in Yum Repo

2012-04-27 Thread tom.yand...@bbc.co.uk (JIRA)
Tom Yandell created JENKINS-13626:
-

 Summary: Include Source RPMs in Yum Repo
 Key: JENKINS-13626
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13626
 Project: Jenkins
  Issue Type: Improvement
  Components: other
Reporter: Tom Yandell
Priority: Minor


Source RPMs are built by the rpm/build.sh script in the Jenkins Git repo, but 
they are not available in the Yum repository:

{code:none}
[root@sandbox ~]# yumdownloader --disablerepo='*' --enablerepo=jenkins --urls 
--source jenkins
...
No source RPM found for jenkins-1.423-1.1.noarch
No source RPM found for jenkins-1.413-1.1.noarch
Nothing to download
{code}

Source RPMs are useful for us to be able to use your packaged version as it 
allows us to review the contents of the package more easily.

--
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-11073) copy artifact fails on windows XP slaves due to failing to set a timestamp

2012-04-27 Thread marnix.klooster+jenk...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162145#comment-162145
 ] 

Marnix Klooster commented on JENKINS-11073:
---

Same problem here with 1.22, not with 1.21.  Master and slave both run on 
Windows Server 2008 R2.  If you need additional info, just ask.

 copy artifact fails on windows XP slaves due to failing to set a timestamp
 --

 Key: JENKINS-11073
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11073
 Project: Jenkins
  Issue Type: Bug
  Components: copyartifact, core
Affects Versions: current
 Environment: Windows XP slave.  CentOS 5.5 server
Reporter: Jeff Koenig
Assignee: kutzi
 Attachments: copyArtifact.txt


 The copy artifact build step fails when it trys to set the time stamp on 
 windows XP slaves.  I have attached the stack trace that shows this error
 Caused by: java.io.IOException: Failed to set the timestamp of 
 C:\automation\AccuNurse-3.2.0.0-569-upgrade.zip to 131655226
 I believe this issue was caused by the changes made for JENKINS-10805.
 I have also found a discussion of others experiencing the same issue 
 http://groups.google.com/group/jenkinsci-users/browse_thread/thread/249ebeb0660d5e0d/e831b70f5688d0c4?show_docid=e831b70f5688d0c4

--
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-13491) Marked line in source code lister of Warnings plugin is not visible

2012-04-27 Thread ullrich.haf...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162146#comment-162146
 ] 

Ulli Hafner commented on JENKINS-13491:
---

Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins 
Analysis Plug-ins (Compile) 
#481|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/481/]
 [FIXED JENKINS-13491] Center the affected source line in source view. 
(Revision 735e37429e4e22a54192a02ce3077872b6a978a7)

 Result = SUCCESS

 Marked line in source code lister of Warnings plugin is not visible
 ---

 Key: JENKINS-13491
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13491
 Project: Jenkins
  Issue Type: Improvement
  Components: warnings
Affects Versions: current
Reporter: Viktor Bekesi
Assignee: Ulli Hafner
Priority: Minor
  Labels: plugins, warnings

 Marked line in source code lister of Warnings plugin is not visible if the 
 code is longer than a page, because the new navigation line of Jenkins covers 
 it. It appears only if user scrolls up a bit.
 It would be nice if the plugin would not jump exactly on the marked line, but 
 some 4-5 lines before. This would solve the problem, and the relevant warning 
 would not be that topmost (could be noticed quicker)

--
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-13624) When using bitbucket as a code browser, links to changeset are incorrect

2012-04-27 Thread benoit.gue...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162148#comment-162148
 ] 

benoit guerin commented on JENKINS-13624:
-

Hum ... sorry, I misconfigured my projet ...

I enter https://bitbucket.org/user/repo/src as the base URL, instead of 
https://bitbucket.org/user/repo/

Perharps a validation of the field url could be a good thing ...

 When using bitbucket as a code browser, links to changeset are incorrect
 

 Key: JENKINS-13624
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13624
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Reporter: benoit guerin
Assignee: Kohsuke Kawaguchi
Priority: Minor

 They are https://bitbucket.org/user/repo/src/changeset/hash/
 The good link is https://bitbucket.org/user/repo/changeset/hash/

--
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-1379) SVN credentials are keyed on hostname only

2012-04-27 Thread tapio...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162149#comment-162149
 ] 

tapiomtr commented on JENKINS-1379:
---

We have same kind problem, and this a blogger to us. The only solution is 
job-specific SVN credentials.

 SVN credentials are keyed on hostname only
 --

 Key: JENKINS-1379
 URL: https://issues.jenkins-ci.org/browse/JENKINS-1379
 Project: Jenkins
  Issue Type: Bug
  Components: security, subversion
Affects Versions: current
 Environment: Platform: PC, OS: Linux
Reporter: jsbournival
Priority: Critical

 We have a couple of projects for which we created Hudson jobs.  We are
 configuring them to pick up source code in SVN, and enter appropriate
 credentials (Hudson tells us it is saving them in its credential safe).  To 
 make
 sure everything's all right, we fire a build right away.  But then, the day
 after, we have an email from hudson saying our build has failed: 
 --
 started
 ERROR: svn: Authorization failed
 org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authorization failed
   at
 org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:47)
   at 
 org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:288)
   at
 org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:210)
   at
 org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:93)
   at
 org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:991)
   at
 org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.checkPath(SVNRepositoryImpl.java:216)
   at
 hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1224)
   at 
 hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1281)
   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:336)
   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:300)
   at hudson.model.AbstractProject.checkout(AbstractProject.java:558)
   at 
 hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:215)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:181)
   at hudson.model.Run.run(Run.java:659)
   at hudson.model.Build.run(Build.java:101)
   at hudson.model.ResourceController.execute(ResourceController.java:70)
   at hudson.model.Executor.run(Executor.java:71)
 Publishing Javadoc
 Recording test results
 So we have to re-enter the credential again each morning.

--
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-13628) Proposal for german translation of DISABLE AUTO REFRESH

2012-04-27 Thread wolfgang.hauser.exter...@cassidian.com (JIRA)
Wolfgang Hauser created JENKINS-13628:
-

 Summary: Proposal for german translation of DISABLE AUTO REFRESH
 Key: JENKINS-13628
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13628
 Project: Jenkins
  Issue Type: Bug
  Components: locale
Affects Versions: current
Reporter: Wolfgang Hauser
Priority: Trivial
 Fix For: current


I would propose the following translation:

english: DISABLE AUTO REFRESH
german [de-de]: Automatischen Update deaktivieren
german[de-at]: Automatischen Update deaktivieren
german[de-ch]: Automatischen Update deaktivieren
german[de-li]: Automatischen Update deaktivieren
german[de-lu]: Automatischen Update deaktivieren

I've tried to use the translation plugin, but the dialog disappears in case of 
automatic update as fast, that it is impossible to enter the text and send 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-13629) When creating a new build in TestLink, plugin should automatically assign test case execution to a user

2012-04-27 Thread robm_campb...@lineone.net (JIRA)
Robert Campbell created JENKINS-13629:
-

 Summary: When creating a new build in TestLink, plugin should 
automatically assign test case execution to a user
 Key: JENKINS-13629
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13629
 Project: Jenkins
  Issue Type: Improvement
  Components: testlink
Affects Versions: current
Reporter: Robert Campbell
Assignee: Bruno P. Kinoshita
Priority: Minor


TestLink only reports some statistics correctly when executed test cases have 
been assigned to a user. Although it is possible to change the assignment 
manually post-execution it would be better if the TestLink plugin did this 
automatically when creating a new build e.g. assign all test cases (to be) 
executed by Jenkins to a jenkins-ci TestLink user.
This may also require changes to the TestLink API.

--
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-13630) TestLink plugin does not update test case execution status correctly

2012-04-27 Thread robm_campb...@lineone.net (JIRA)
Robert Campbell created JENKINS-13630:
-

 Summary: TestLink plugin does not update test case execution 
status correctly
 Key: JENKINS-13630
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13630
 Project: Jenkins
  Issue Type: Bug
  Components: testlink
Affects Versions: current
 Environment: Windows 2003, TestLink 1.9.3, Jenkins 1.461, TestLink 
Plugin 3.1.2
Reporter: Robert Campbell
Assignee: Bruno P. Kinoshita
Priority: Minor
 Attachments: TestCase_result_bug.jpg

Using the jenkins-testlink-plugin-tutorial example, the test case is executed 
correctly and is passed as part of the Jenkins job. Under Test Execution in 
TestLink the test case Status is reported as Passed yet the Result is still set 
to Not Run. See attached screenshot.

--
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-13629) When creating a new build in TestLink, plugin should automatically assign test case execution to a user

2012-04-27 Thread brunodepau...@yahoo.com.br (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162150#comment-162150
 ] 

Bruno P. Kinoshita commented on JENKINS-13629:
--

Hmm, good RFE. We may really need to change a few things in TestLink API, but 
that will be a great feature. Last week I was working on another project, but 
in May I will work on Jenkins and plug-ins again. Thanks for reporting, will 
try to work on this as soon as possible.

 When creating a new build in TestLink, plugin should automatically assign 
 test case execution to a user
 ---

 Key: JENKINS-13629
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13629
 Project: Jenkins
  Issue Type: Improvement
  Components: testlink
Affects Versions: current
Reporter: Robert Campbell
Assignee: Bruno P. Kinoshita
Priority: Minor
  Labels: jenkins, plugins, testlink

 TestLink only reports some statistics correctly when executed test cases have 
 been assigned to a user. Although it is possible to change the assignment 
 manually post-execution it would be better if the TestLink plugin did this 
 automatically when creating a new build e.g. assign all test cases (to be) 
 executed by Jenkins to a jenkins-ci TestLink user.
 This may also require changes to the TestLink API.

--
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-13622) ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.

2012-04-27 Thread daniel.peti...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162152#comment-162152
 ] 

Daniel Petisme commented on JENKINS-13622:
--

Can you check if your issue is similar to this one please:
[JENKINS-9539|https://issues.jenkins-ci.org/browse/JENKINS-9539]
The last time I've tried, I saw both message in the same log. To know if is the 
same issue.

 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 -

 Key: JENKINS-13622
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13622
 Project: Jenkins
  Issue Type: Bug
  Components: qc
Affects Versions: current
 Environment: - Microsoft Windows XP Professional SP 3
 - IE 8  Chrome
 - Jenkins ver. 1.451
 - qc plugin 1.2.1
Reporter: COE CI
Assignee: Daniel Petisme
  Labels: plugin

 +--+
 | Test Name| 
 Status|
 +--+
 | [1]MercuryTours  | 
 Passed|
 +--+
 ..\runTestSet.vbs(555, 5) ADODB.Stream: Write to file failed.
 FATAL: Tests report not generated
 Build step 'HP Quality Center' marked build as failure
 Sending e-mails to: 
 Finished: FAILURE

--
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-10502) Add an option to make archiving the artifacts non-fatal if they don't exist

2012-04-27 Thread thomasmfie...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162153#comment-162153
 ] 

Thomas Fields commented on JENKINS-10502:
-

Thanks for that, it sounds like the biggest hack ever. We should be able to 
configure this on a project level and not globally for the whole system.

Cheers,
Tom.

 Add an option to make archiving the artifacts non-fatal if they don't exist
 ---

 Key: JENKINS-10502
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10502
 Project: Jenkins
  Issue Type: Improvement
  Components: core
 Environment: Jenkins 1.421
Reporter: Thomas Fields

 If you tick the box to enable Archive the artifacts, populate the Files to 
 archive, and your build fails to output those artifacts it will fail with 
 something like this:
 {code}
 12:11:51  Archiving artifacts
 12:11:51  ERROR: No artifacts found that match the file pattern 
 tfields/Live/Engine/Tools/Layout.*. Configuration error?
 12:11:57  ERROR: 'tfields/Live/Engine/Tools/Layout.*' doesn't match anything: 
 'tfields' exists but not 'tfields/Live/Engine/Tools/Layout.*'
 12:11:57  Build step 'Archive the artifacts' changed build result to FAILURE
 {code}
 Depending on what your build actually does, those artifacts might not always 
 be created. I'd like to propose that you add an option to make the archiving 
 of artifacts non fatal.
 Thanks,
 Tom.

--
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-13530) JENKINS_HOME ignored on Bundled Windows EXE.

2012-04-27 Thread matthew.n.oconn...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162155#comment-162155
 ] 

Matthew O'Connell commented on JENKINS-13530:
-

Confirmed. Installed Jenkins in C:\Program Files (x86)\ and trying to set 
JENKINS_HOME to E: drive - no dice :-/

 JENKINS_HOME ignored on Bundled Windows EXE.
 

 Key: JENKINS-13530
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13530
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Windows XP.
Reporter: Mike Caspar
  Labels: windows

 I've been having trouble with the JENKINS_HOME and think I've figured out a 
 way around the problem, but at the same time, would like to report a problem 
 with the BUNDLED download.
 At FIRST, I thought I was doing something wrong, but have confirmed the 
 problem does NOT exist in the WAR that I install into my Tomcat 7 server.
 If I load the SETUP.EXE, when the SERVICE starts up, it simply IGNORED my 
 System Environment variables completely.  Nothing I do changes this.
 If I stop the service and download the WAR and load it into Tomcat it 
 PROPERLY reads the Environment Variable and locates the appropriate folder.
 Again, the problem is only with the windows Service Installer from the 
 Windows Setup.
 I have even set HUDSON_HOME (just in case).
 Thanks
 (wasn't sure if CORE was the right place to put this).

--
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-13530) JENKINS_HOME ignored on Bundled Windows EXE.

2012-04-27 Thread matthew.n.oconn...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162155#comment-162155
 ] 

Matthew O'Connell edited comment on JENKINS-13530 at 4/27/12 1:33 PM:
--

Confirmed. Installed Jenkins on Win 2008 R2 Server in C:\Program Files (x86)\ 
and trying to set JENKINS_HOME to E: drive - no dice :-/

  was (Author: ultra99):
Confirmed. Installed Jenkins in C:\Program Files (x86)\ and trying to set 
JENKINS_HOME to E: drive - no dice :-/
  
 JENKINS_HOME ignored on Bundled Windows EXE.
 

 Key: JENKINS-13530
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13530
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Windows XP.
Reporter: Mike Caspar
  Labels: windows

 I've been having trouble with the JENKINS_HOME and think I've figured out a 
 way around the problem, but at the same time, would like to report a problem 
 with the BUNDLED download.
 At FIRST, I thought I was doing something wrong, but have confirmed the 
 problem does NOT exist in the WAR that I install into my Tomcat 7 server.
 If I load the SETUP.EXE, when the SERVICE starts up, it simply IGNORED my 
 System Environment variables completely.  Nothing I do changes this.
 If I stop the service and download the WAR and load it into Tomcat it 
 PROPERLY reads the Environment Variable and locates the appropriate folder.
 Again, the problem is only with the windows Service Installer from the 
 Windows Setup.
 I have even set HUDSON_HOME (just in case).
 Thanks
 (wasn't sure if CORE was the right place to put this).

--
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-3922) Slave is slow copying maven artifacts to master

2012-04-27 Thread jimmi.dy...@specsavers.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162156#comment-162156
 ] 

Jimmi Dyson commented on JENKINS-3922:
--

I've updated the ssh slaves plugin to use JSch  all works fine.

But it doesn't solve the SFTP speed issue... that would appear to be because it 
uses _hudson.util.ssh.SFTPClient_ instead of the one in the ssh slaves plugin. 
I can't figure out where this class is created though? Am I missing something? 
I'd like to refactor this as well to use JSch, but the constructor uses 
_com.trilead.ssh2.Connection_ so need to know where it's created to refactor as 
well. Any ideas?

 Slave is slow copying maven artifacts to master
 ---

 Key: JENKINS-3922
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3922
 Project: Jenkins
  Issue Type: Bug
  Components: master-slave
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: John McNair
Assignee: Kohsuke Kawaguchi
Priority: Critical
 Attachments: pom.xml


 The artifact transfer is currently a 3-4x penalty for the project that I am
 working on.  I have reproduced the issue with a simple test pom that does
 nothing but jar hudson.war.  I performed this test on a heterogeneous
 environment.  Both master and slave are running Fedora 10, but the master is a
 faster machine.  Still, it highlights the issue.
 Here are some stats (all stats are after caching dependencies in the local 
 repos):
 Master build through Hudson: 19s
 Master build from command line (no Hudson): 9s
 Slave build through Hudson: 1m46s
 Slave build from command line (no Hudson): 16s
 To be fair we should at least add time to do a straight scp of the artifact 
 from
 slave to master.  The two nodes share a 100 Mbit switch:
 $ scp target/slow-rider-1.0.0-SNAPSHOT.jar master_node:
 slow-rider-1.0.0NAPSHOT.jar  100%   25MB  12.7MB/s   00:02
 Of course this example exaggerates the issue to make it more clear but not by
 too much.  I originally noticed this in a completely separate environment that
 was all virtual.  I reproduced this on two physical machines using a different
 switch and different ethernet drivers (both virtual and physical).  The
 reproducibility plus the comparison against command line + scp leads me to
 suspect eager flushing.

--
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-13631) Can't manually promote build with

2012-04-27 Thread aurelien.pellet...@gmail.com (JIRA)
Aurélien Pelletier created JENKINS-13631:


 Summary: Can't manually promote build with 
 Key: JENKINS-13631
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Affects Versions: current
 Environment: debian 5
Oracle JDK 1.6.0_12
Jenkins 1.461
Reporter: Aurélien Pelletier


Promoted build plugin version 2.5, it works with version 2.4

I have a job configured with a manually approved + approval parameter promotion.

When I try to promoted the build using the Approve button to pass the 
parameters I get an error 500 with this stack trace:

java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB
at hudson.maven.ModuleName.fromString(ModuleName.java:97)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117)
at jenkins.model.Jenkins.getItem(Jenkins.java:2159)
at jenkins.model.Jenkins.getItem(Jenkins.java:2180)
at 
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
 

--
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-13631) Can't manually promote build with approval parameter

2012-04-27 Thread aurelien.pellet...@gmail.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aurélien Pelletier updated JENKINS-13631:
-

Summary: Can't manually promote build with approval parameter  (was: Can't 
manually promote build with )

 Can't manually promote build with approval parameter
 

 Key: JENKINS-13631
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Affects Versions: current
 Environment: debian 5
 Oracle JDK 1.6.0_12
 Jenkins 1.461
Reporter: Aurélien Pelletier
  Labels: plugin

 Promoted build plugin version 2.5, it works with version 2.4
 I have a job configured with a manually approved + approval parameter 
 promotion.
 When I try to promoted the build using the Approve button to pass the 
 parameters I get an error 500 with this stack trace:
 java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB
 at hudson.maven.ModuleName.fromString(ModuleName.java:97)
 at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354)
 at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117)
 at jenkins.model.Jenkins.getItem(Jenkins.java:2159)
 at jenkins.model.Jenkins.getItem(Jenkins.java:2180)
 at 
 hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
  

--
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-13632) AbstractMethodError with PTC Integrity Plugin

2012-04-27 Thread oliver.ha...@daimler.com (JIRA)
O H created JENKINS-13632:
-

 Summary: AbstractMethodError with PTC Integrity Plugin
 Key: JENKINS-13632
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13632
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
 Environment: - Jenkins ver. 1.461
- Windows Server 2008 R2
- Integrity Plugin version 1.12
Reporter: O H
Assignee: Cletus D'Souza


I get the following error after I upgraded Jenkins as well as the plugin:

16:51:33  FATAL: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33  java.lang.AbstractMethodError: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
16:51:33at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.handleHTTPResponse(UserApplicationSessionImpl.java:304)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSession(UserApplicationSessionImpl.java:350)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSessionURI(UserApplicationSessionImpl.java:413)
16:51:33at 
com.mks.connect.HttpCmdRunnerImpl.getSessionURI(HttpCmdRunnerImpl.java:72)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.getSessionURI(HttpBlimpInputStream.java:125)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.blimpInitiate(HttpBlimpInputStream.java:152)
16:51:33at 
com.mks.connect.BlimpInputStream.getInputStream(BlimpInputStream.java:223)
16:51:33at 
com.mks.connect.BlimpInputStream.readNoEof(BlimpInputStream.java:693)
16:51:33at 
com.mks.connect.BlimpInputStream.handleNextBlimpCommand(BlimpInputStream.java:266)
16:51:33at 
com.mks.connect.BlimpInputStream.read(BlimpInputStream.java:190)

--
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-13633) Linux master + Windows slave: problem with polling when global configuration for Clearcase is set

2012-04-27 Thread w.male...@gmail.com (JIRA)
Waldek M created JENKINS-13633:
--

 Summary: Linux master + Windows slave: problem with polling when 
global configuration for Clearcase is set
 Key: JENKINS-13633
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13633
 Project: Jenkins
  Issue Type: Bug
  Components: clearcase
 Environment: master: RHEL 5.5
slave: MS Windows XP SP3
Reporter: Waldek M
Assignee: Vincent Latombe
Priority: Minor


My configuration was:
- general settings: Clearcase path set to /usr/atria
- Windows node slave settings: Clearcase path set to C:\Program 
Files\Rational\Clearcase

The log from clearcase polling showed that even on Windows slave, the cleartool 
with path from global settings was used, and showed nothing.

Started on Apr 27, 2012 4:58:22 PM
[my_view] $ /usr/atria/bin/cleartool pwv -root
[MyJob] $ /usr/atria/bin/cleartool lsview my_view
Done. Took 15 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-13591) Plugin doesn't support jenkins URL prefix (--prefix option)

2012-04-27 Thread ludovic.meuril...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162158#comment-162158
 ] 

Ludovic Meurillon commented on JENKINS-13591:
-

I tried my changes locally in two different contexts mvn hpi:run and mvn 
hpi:run -Dhpi.prefix=jenkins

I also tested it on different pages like Administration, sub menus, show 
console from last build etc...

Does it seems enough from your point of view ? If you know some complex test 
case that could be broken, don't hesitate to challenge me ;)

I will use this version on my team's instance to test accross our views but if 
it's enough I'll do a pull request as soon as possible.

 Plugin doesn't support jenkins URL prefix (--prefix option)
 ---

 Key: JENKINS-13591
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13591
 Project: Jenkins
  Issue Type: Bug
  Components: html5-notifier
Affects Versions: current
Reporter: Ludovic Meurillon
Assignee: jieryn

 My jenkins is running behind an apache server, my configuration is very 
 simple and look like this one : 
 https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache
 The plugin doesn't work with this configuration because absolute URL are used 
 into the javascript code, for example in html5-notification.js there is a 
 ...new Ajax.Request('/html5-notifier-plugin/list')...
 that refer in my case to http://HOST/html5-notifier-plugin/list, but the 
 real list is at http://HOST/jenkins/html5-notifier-plugin/list
 It might be a Jenkins way to get the server URL properly and inject it into 
 js files or java generated js code.
 Ludovic.

--
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-13632) AbstractMethodError with PTC Integrity Plugin

2012-04-27 Thread oliver.ha...@daimler.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

O H updated JENKINS-13632:
--

Description: 
I get the following error after I upgraded Jenkins as well as the plugin:

16:51:33  FATAL: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33  java.lang.AbstractMethodError: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
16:51:33at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.handleHTTPResponse(UserApplicationSessionImpl.java:304)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSession(UserApplicationSessionImpl.java:350)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSessionURI(UserApplicationSessionImpl.java:413)
16:51:33at 
com.mks.connect.HttpCmdRunnerImpl.getSessionURI(HttpCmdRunnerImpl.java:72)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.getSessionURI(HttpBlimpInputStream.java:125)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.blimpInitiate(HttpBlimpInputStream.java:152)
16:51:33at 
com.mks.connect.BlimpInputStream.getInputStream(BlimpInputStream.java:223)
16:51:33at 
com.mks.connect.BlimpInputStream.readNoEof(BlimpInputStream.java:693)
16:51:33at 
com.mks.connect.BlimpInputStream.handleNextBlimpCommand(BlimpInputStream.java:266)
16:51:33at 
com.mks.connect.BlimpInputStream.read(BlimpInputStream.java:190)

When I downgrade to Jenkins 1.419 everything works fine again!

  was:
I get the following error after I upgraded Jenkins as well as the plugin:

16:51:33  FATAL: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33  java.lang.AbstractMethodError: 
com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
16:51:33at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
16:51:33at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
16:51:33at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
16:51:33at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.handleHTTPResponse(UserApplicationSessionImpl.java:304)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSession(UserApplicationSessionImpl.java:350)
16:51:33at 
com.mks.connect.UserApplicationSessionImpl.getSessionURI(UserApplicationSessionImpl.java:413)
16:51:33at 
com.mks.connect.HttpCmdRunnerImpl.getSessionURI(HttpCmdRunnerImpl.java:72)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.getSessionURI(HttpBlimpInputStream.java:125)
16:51:33at 
com.mks.connect.HttpBlimpInputStream.blimpInitiate(HttpBlimpInputStream.java:152)
16:51:33at 
com.mks.connect.BlimpInputStream.getInputStream(BlimpInputStream.java:223)
16:51:33at 
com.mks.connect.BlimpInputStream.readNoEof(BlimpInputStream.java:693)
16:51:33at 
com.mks.connect.BlimpInputStream.handleNextBlimpCommand(BlimpInputStream.java:266)
16:51:33at 
com.mks.connect.BlimpInputStream.read(BlimpInputStream.java:190)


 AbstractMethodError with PTC Integrity Plugin
 -

 Key: JENKINS-13632
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13632
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
 

[JIRA] (JENKINS-3922) Slave is slow copying maven artifacts to master

2012-04-27 Thread jimmi.dy...@specsavers.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162156#comment-162156
 ] 

Jimmi Dyson edited comment on JENKINS-3922 at 4/27/12 3:31 PM:
---

I've updated the ssh slaves plugin to use JSch  all works fine for connection, 
starting, running builds, disconnecting, etc. But it doesn't solve the SFTP 
speed issue... I now realise that it doesn't actually use SFTP for archiving 
artifacts back to the master - that is done through the FilePath abstraction I 
believe. So the speed issue should exist in all slave types, such as JNLP?

So why is this slow? In our environment, doing native SSH transfers takes 
around 10 seconds for a 100MB transfer. Jenkins archiving a 100MB artifact 
takes about 50 seconds using an SSH slave.

  was (Author: jimmidyson):
I've updated the ssh slaves plugin to use JSch  all works fine.

But it doesn't solve the SFTP speed issue... that would appear to be because it 
uses _hudson.util.ssh.SFTPClient_ instead of the one in the ssh slaves plugin. 
I can't figure out where this class is created though? Am I missing something? 
I'd like to refactor this as well to use JSch, but the constructor uses 
_com.trilead.ssh2.Connection_ so need to know where it's created to refactor as 
well. Any ideas?
  
 Slave is slow copying maven artifacts to master
 ---

 Key: JENKINS-3922
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3922
 Project: Jenkins
  Issue Type: Bug
  Components: master-slave
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: John McNair
Assignee: Kohsuke Kawaguchi
Priority: Critical
 Attachments: pom.xml


 The artifact transfer is currently a 3-4x penalty for the project that I am
 working on.  I have reproduced the issue with a simple test pom that does
 nothing but jar hudson.war.  I performed this test on a heterogeneous
 environment.  Both master and slave are running Fedora 10, but the master is a
 faster machine.  Still, it highlights the issue.
 Here are some stats (all stats are after caching dependencies in the local 
 repos):
 Master build through Hudson: 19s
 Master build from command line (no Hudson): 9s
 Slave build through Hudson: 1m46s
 Slave build from command line (no Hudson): 16s
 To be fair we should at least add time to do a straight scp of the artifact 
 from
 slave to master.  The two nodes share a 100 Mbit switch:
 $ scp target/slow-rider-1.0.0-SNAPSHOT.jar master_node:
 slow-rider-1.0.0NAPSHOT.jar  100%   25MB  12.7MB/s   00:02
 Of course this example exaggerates the issue to make it more clear but not by
 too much.  I originally noticed this in a completely separate environment that
 was all virtual.  I reproduced this on two physical machines using a different
 switch and different ethernet drivers (both virtual and physical).  The
 reproducibility plus the comparison against command line + scp leads me to
 suspect eager flushing.

--
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-8600) allow adding sidebar links to build pages

2012-04-27 Thread direv...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162160#comment-162160
 ] 

Alexey Lavrenuke commented on JENKINS-8600:
---

I wrote a plugin that allows you to add links from a text file to every build. 
It would help maybe.
https://wiki.jenkins-ci.org/display/JENKINS/AnchorChain+plugin

 allow adding sidebar links to build pages
 -

 Key: JENKINS-8600
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8600
 Project: Jenkins
  Issue Type: Improvement
  Components: sidebar-link
Reporter: Marcus Better

 I would like to add sidebar links to the build pages, not just the project 
 page. It should allow expansion of build variables in the URL.

--
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-13569) Unable to publish artifacts to home page of a confluence space due to NPE

2012-04-27 Thread jhans...@myyearbook.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on JENKINS-13569 started by Joe Hansche.

 Unable to publish artifacts to home page of a confluence space due to NPE
 -

 Key: JENKINS-13569
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13569
 Project: Jenkins
  Issue Type: Bug
  Components: confluence-publisher
Affects Versions: current
 Environment: Jenkins ver. 1.460
 Atlassian Confluence 4.0
 Windows 2003
 User with good rights configured at confluence side
 Confluence site configured at Jenkins side
Reporter: madriman madriman
Assignee: Joe Hansche
Priority: Blocker

 [confluence] Uploading attachments to Confluence page: 
 http://confluence.xxx.com/display/SOFTRELEASE/Home
 ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher 
 aborted due to exception
 java.lang.NullPointerException
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.findArtifacts(ConfluencePublisher.java:402)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performAttachments(ConfluencePublisher.java:170)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:291)
   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
   at hudson.model.Run.run(Run.java:1446)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Finished: FAILURE

--
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-13569) Unable to publish artifacts to home page of a confluence space due to NPE

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162161#comment-162161
 ] 

SCM/JIRA link daemon commented on JENKINS-13569:


Code changed in jenkins
User: Joe Hansche
Path:
 src/main/java/com/myyearbook/hudson/plugins/confluence/ConfluencePublisher.java
http://jenkins-ci.org/commit/confluence-publisher-plugin/c712a3c4af6e444febb2b5a3c50f69e1abcf9339
Log:
  [Fix JENKINS-13569] Don't look for artifacts if there are none.

If attach archived artifacts is checked, but the Archive the artifacts
post-build option is not, attemping to look for artifacts results in
a NPE.


Compare: 
https://github.com/jenkinsci/confluence-publisher-plugin/compare/52a0e81...c712a3c



 Unable to publish artifacts to home page of a confluence space due to NPE
 -

 Key: JENKINS-13569
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13569
 Project: Jenkins
  Issue Type: Bug
  Components: confluence-publisher
Affects Versions: current
 Environment: Jenkins ver. 1.460
 Atlassian Confluence 4.0
 Windows 2003
 User with good rights configured at confluence side
 Confluence site configured at Jenkins side
Reporter: madriman madriman
Assignee: Joe Hansche
Priority: Blocker

 [confluence] Uploading attachments to Confluence page: 
 http://confluence.xxx.com/display/SOFTRELEASE/Home
 ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher 
 aborted due to exception
 java.lang.NullPointerException
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.findArtifacts(ConfluencePublisher.java:402)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performAttachments(ConfluencePublisher.java:170)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:291)
   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
   at hudson.model.Run.run(Run.java:1446)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Finished: FAILURE

--
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-13533) Maven build fails on CleanTempFilesAction#tempFiles serialization

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162162#comment-162162
 ] 

SCM/JIRA link daemon commented on JENKINS-13533:


Code changed in jenkins
User: imod
Path:
 
src/main/java/org/jenkinsci/plugins/configfiles/buildwrapper/CleanTempFilesAction.java
 
src/main/java/org/jenkinsci/plugins/configfiles/buildwrapper/CleanTempFilesRunListener.java
 
src/main/java/org/jenkinsci/plugins/configfiles/buildwrapper/ConfigFileBuildWrapper.java
http://jenkins-ci.org/commit/config-file-provider-plugin/0e8baa31110b0dca74a2950a9e3e90e6c48ba330
Log:
  [FIXED JENKINS-13533] Maven build fails on CleanTempFilesAction#tempFiles 
serialization






 Maven build fails on CleanTempFilesAction#tempFiles serialization
 -

 Key: JENKINS-13533
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13533
 Project: Jenkins
  Issue Type: Bug
  Components: config-file-provider
 Environment: config-file-provider 2.1
 Jenkins 1.460
Reporter: mdp
Assignee: domi

 A Maven project build (on a remote slave) fails with:
 org.apache.maven.InternalErrorException: Internal error: 
 java.lang.RuntimeException: Failed to serialize 
 hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild
   at 
 org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
   at 
 org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
   at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
   at hudson.remoting.Request$2.run(Request.java:287)
   at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.RuntimeException: Failed to serialize 
 hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild
   at 
 hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167)
   at 
 hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135)
   at 
 com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130)
   at 
 hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:120)
   at 
 hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:94)
   at 
 com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
   at 
 com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
   at 
 com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
   at 
 com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:98)
   at 
 com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:38)
   at com.thoughtworks.xstream.XStream.marshal(XStream.java:840)
   at com.thoughtworks.xstream.XStream.marshal(XStream.java:829)
   at 

[JIRA] (JENKINS-9714) In Check-out Strategy there are separate revert and clean options, but there is no clean and revert option.

2012-04-27 Thread avoll...@audible.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162163#comment-162163
 ] 

Adam Vollmer commented on JENKINS-9714:
---

I ran into a build issue recently because one of our build scripts changed, so 
a now-vestigal directory was causing problems because it was no longer being 
cleaned up. the execution was

Jenkins runs old-build-script clean which cleans foo/lib
Jenkins runs old-build-script build which creates foo/lib and populates it
build script change is checked in
Jenkins runs new-build-script clean which no longer cleans foo/lib
Jenkins runs new-build-script build which no longer creates foo/lib, but the 
old content is there.

The only real workaround on my end is to always be vigilant for all possible 
places that code could possibly affect my build and preemptively clean them in 
all cases, regardless of whether I'd place anything there. That puts a huge 
burden on me.

 In Check-out Strategy there are separate revert and clean options, but 
 there is no clean and revert option. 
 

 Key: JENKINS-9714
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9714
 Project: Jenkins
  Issue Type: Improvement
  Components: subversion
Affects Versions: current
 Environment: Tested on Windows 32 bits running as a service, but it 
 should occur on any environment.
Reporter: Jader Dias

 My project needs to have all new files deleted and existing files to be 
 reverted before each update. I can only choose one or the other, I need both.

--
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-13635) Backup warnings when performing tar.gz

2012-04-27 Thread casu...@gmail.com (JIRA)
A K created JENKINS-13635:
-

 Summary: Backup warnings when performing tar.gz
 Key: JENKINS-13635
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13635
 Project: Jenkins
  Issue Type: Bug
  Components: periodicbackup
 Environment: Jenkins 1.459, Running on Ubuntu Linux.
Periodic Backup Version 1.1
Reporter: A K
Priority: Minor


The jenkins log is filled with lines like the following (whenever it goes to do 
a backup):
[INFO] Building tar: ...
...
[WARNING] Entry: jobs/.../.../.../... longer than 100 characters
...

The backups appear to be completing still, but am not 100% sure if the tar 
files are corrupt or not.

Doing my own minor research indicates that adding the '-E' flag will allow for 
longer filenames, so perhaps this is something that should be added to the 
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-13636) notifyCommit method requires cookie, even when anonymous has build permission in ACL

2012-04-27 Thread glfk...@gmail.com (JIRA)
Rodney Stanton created JENKINS-13636:


 Summary: notifyCommit method requires cookie, even when anonymous 
has build permission in ACL
 Key: JENKINS-13636
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13636
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial, security
Affects Versions: current
 Environment: linux
Reporter: Rodney Stanton
Assignee: Kohsuke Kawaguchi


When using Enable Security and Mercurial, the notifyCommit method fails even 
when anonymous has build permissions. The difference appears to be in the 
cookies.

Failed case:
GET /mercurial/notifyCommit?url=ssh://redacted/sandbox HTTP/1.1
User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b 
zlib/1.2.3 libidn/0.6.5
Host: redacted:8080
Accept: */*

HTTP/1.1 200 OK
Server: Winstone Servlet Engine v0.9.10
Content-Type: text/plain;charset=ISO-8859-1
Connection: Close
Date: Fri, 27 Apr 2012 17:37:29 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
Set-Cookie: JSESSIONID.79b17db3=3480193c16b0d5371437749c981fa1be; Path=/; 
HttpOnly

No mercurial jobs found


SUCCESS:
GET /mercurial/notifyCommit?url=ssh://redacted/sandbox HTTP/1.1
Host: redacted:8080
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20100101 
Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,ja;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Cookie: __utma=142065709.672751542.1326231118.1326319384.1331761724.3; 
__utmz=142065709.1331761724.3.2.utmcsr=t.co|utmccn=(referral)|utmcmd=referral|utmcct=/M7DYDoPx;
 _mkto_trk=id:364-BLA-665token:_mch-redacted-1326231118044-34632; 
iconSize=16x16; 
ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=cnN0YW50b246MTMzNjQzMTg4NTIyOTpjN2U0ZTI4MGNiMGNkNTk2YTk0MmEwNjlkMDZkNDI5ZQ==;
 JSESSIONID.52356e8f=637ee763053a1b7d5ff29fd9a54088df; 
screenResolution=1920x1080
Cache-Control: max-age=0

HTTP/1.1 200 OK
Server: Winstone Servlet Engine v0.9.10
Content-Type: text/plain;charset=ISO-8859-1
Triggered: http://redacted/job/testjob/
Connection: Close
Date: Fri, 27 Apr 2012 17:36:04 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
Set-Cookie: JSESSIONID.79b17db3=68d15f2b379727128525f7f3933eae27; Path=/; 
HttpOnly

--
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-13518) Wrong JSON syntax

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162165#comment-162165
 ] 

SCM/JIRA link daemon commented on JENKINS-13518:


Code changed in jenkins
User: imod
Path:
 pom.xml
 src/main/java/org/jenkinsci/plugins/scriptler/util/UIHelper.java
 
src/main/resources/org/jenkinsci/plugins/scriptler/builder/ScriptlerBuilder/config.jelly
 
src/test/java/org/jenkinsci/plugins/scriptler/share/scriptlerweb/UIHelperTest.java
 src/test/resources/JENKINS-13518.json
 src/test/resources/simple1.json
 src/test/resources/simple2.json
http://jenkins-ci.org/commit/scriptler-plugin/f754210dfca51bb0e5fb93ab59537748cd38501b
Log:
  [FIXED JENKINS-13518] Wrong JSON syntax




 Wrong JSON syntax
 -

 Key: JENKINS-13518
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13518
 Project: Jenkins
  Issue Type: Bug
  Components: scriptler
Affects Versions: current
 Environment: OSX 10.7.3
 java version 1.6.0_31
 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
 Jenkins 1.460
Reporter: Florian Schwab
Assignee: domi
  Labels: plugin

 If I try adding a script with scriptler to a job I get the following 
 exception:
 Failed to parse form data. Please report this problem as a bug
 JSON={:,builder:{backupJobName:,builderId:,defineParams:false,kind:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder,parameters:[{name:,value:},{name:,value:}],scriptlerScriptId:testOutput.groovy,stapler-class:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder},core:apply:,description:,displayNameOrNull:,name:test,properties:{hudson-model-ParametersDefinitionProperty:{},org-jenkinsci-plugins-envinject-EnvInjectJobProperty:{},stapler-class-bag:true},scm:{value:0}}
 net.sf.json.JSONException: JSONObject[defineParams] is not a JSONObject.
   at net.sf.json.JSONObject.getJSONObject(JSONObject.java:1759)
   at 
 org.jenkinsci.plugins.scriptler.util.UIHelper.extractParameters(UIHelper.java:22)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:161)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:109)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
   at hudson.util.DescribableList.rebuildHetero(DescribableList.java:184)
   at hudson.model.Project.submit(Project.java:197)
   at hudson.model.Job.doConfigSubmit(Job.java:990)
   at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:665)
   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:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
   at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
   at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
   at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
   at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java: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)
  

[JIRA] (JENKINS-13518) Wrong JSON syntax

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

SCM/JIRA link daemon resolved JENKINS-13518.


Resolution: Fixed

 Wrong JSON syntax
 -

 Key: JENKINS-13518
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13518
 Project: Jenkins
  Issue Type: Bug
  Components: scriptler
Affects Versions: current
 Environment: OSX 10.7.3
 java version 1.6.0_31
 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
 Jenkins 1.460
Reporter: Florian Schwab
Assignee: domi
  Labels: plugin

 If I try adding a script with scriptler to a job I get the following 
 exception:
 Failed to parse form data. Please report this problem as a bug
 JSON={:,builder:{backupJobName:,builderId:,defineParams:false,kind:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder,parameters:[{name:,value:},{name:,value:}],scriptlerScriptId:testOutput.groovy,stapler-class:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder},core:apply:,description:,displayNameOrNull:,name:test,properties:{hudson-model-ParametersDefinitionProperty:{},org-jenkinsci-plugins-envinject-EnvInjectJobProperty:{},stapler-class-bag:true},scm:{value:0}}
 net.sf.json.JSONException: JSONObject[defineParams] is not a JSONObject.
   at net.sf.json.JSONObject.getJSONObject(JSONObject.java:1759)
   at 
 org.jenkinsci.plugins.scriptler.util.UIHelper.extractParameters(UIHelper.java:22)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:161)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:109)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
   at hudson.util.DescribableList.rebuildHetero(DescribableList.java:184)
   at hudson.model.Project.submit(Project.java:197)
   at hudson.model.Job.doConfigSubmit(Job.java:990)
   at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:665)
   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:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
   at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
   at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
   at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
   at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java: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.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
   at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
   at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
   at 

[JIRA] (JENKINS-13518) Wrong JSON syntax

2012-04-27 Thread dogf...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162166#comment-162166
 ] 

dogfood commented on JENKINS-13518:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_scriptler #50|http://ci.jenkins-ci.org/job/plugins_scriptler/50/]
 [FIXED JENKINS-13518] Wrong JSON syntax (Revision 
f754210dfca51bb0e5fb93ab59537748cd38501b)

 Result = SUCCESS
imod : 
Files : 
* src/test/resources/JENKINS-13518.json
* 
src/test/java/org/jenkinsci/plugins/scriptler/share/scriptlerweb/UIHelperTest.java
* src/test/resources/simple2.json
* src/main/java/org/jenkinsci/plugins/scriptler/util/UIHelper.java
* src/test/resources/simple1.json
* 
src/main/resources/org/jenkinsci/plugins/scriptler/builder/ScriptlerBuilder/config.jelly
* pom.xml


 Wrong JSON syntax
 -

 Key: JENKINS-13518
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13518
 Project: Jenkins
  Issue Type: Bug
  Components: scriptler
Affects Versions: current
 Environment: OSX 10.7.3
 java version 1.6.0_31
 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
 Jenkins 1.460
Reporter: Florian Schwab
Assignee: domi
  Labels: plugin

 If I try adding a script with scriptler to a job I get the following 
 exception:
 Failed to parse form data. Please report this problem as a bug
 JSON={:,builder:{backupJobName:,builderId:,defineParams:false,kind:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder,parameters:[{name:,value:},{name:,value:}],scriptlerScriptId:testOutput.groovy,stapler-class:org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder},core:apply:,description:,displayNameOrNull:,name:test,properties:{hudson-model-ParametersDefinitionProperty:{},org-jenkinsci-plugins-envinject-EnvInjectJobProperty:{},stapler-class-bag:true},scm:{value:0}}
 net.sf.json.JSONException: JSONObject[defineParams] is not a JSONObject.
   at net.sf.json.JSONObject.getJSONObject(JSONObject.java:1759)
   at 
 org.jenkinsci.plugins.scriptler.util.UIHelper.extractParameters(UIHelper.java:22)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:161)
   at 
 org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:109)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
   at 
 hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
   at hudson.util.DescribableList.rebuildHetero(DescribableList.java:184)
   at hudson.model.Project.submit(Project.java:197)
   at hudson.model.Job.doConfigSubmit(Job.java:990)
   at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:665)
   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:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
   at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
   at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
   at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
   at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
   at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
   at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
   at 

[JIRA] (JENKINS-13569) Unable to publish artifacts to home page of a confluence space due to NPE

2012-04-27 Thread jhans...@myyearbook.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Hansche resolved JENKINS-13569.
---

  Assignee: madriman madriman  (was: Joe Hansche)
Resolution: Fixed

Fixed and released in 1.5

 Unable to publish artifacts to home page of a confluence space due to NPE
 -

 Key: JENKINS-13569
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13569
 Project: Jenkins
  Issue Type: Bug
  Components: confluence-publisher
Affects Versions: current
 Environment: Jenkins ver. 1.460
 Atlassian Confluence 4.0
 Windows 2003
 User with good rights configured at confluence side
 Confluence site configured at Jenkins side
Reporter: madriman madriman
Assignee: madriman madriman
Priority: Blocker

 [confluence] Uploading attachments to Confluence page: 
 http://confluence.xxx.com/display/SOFTRELEASE/Home
 ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher 
 aborted due to exception
 java.lang.NullPointerException
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.findArtifacts(ConfluencePublisher.java:402)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performAttachments(ConfluencePublisher.java:170)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:291)
   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
   at hudson.model.Run.run(Run.java:1446)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Finished: FAILURE

--
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-13569) Unable to publish artifacts to home page of a confluence space due to NPE

2012-04-27 Thread jhans...@myyearbook.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on JENKINS-13569 stopped by Joe Hansche.

 Unable to publish artifacts to home page of a confluence space due to NPE
 -

 Key: JENKINS-13569
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13569
 Project: Jenkins
  Issue Type: Bug
  Components: confluence-publisher
Affects Versions: current
 Environment: Jenkins ver. 1.460
 Atlassian Confluence 4.0
 Windows 2003
 User with good rights configured at confluence side
 Confluence site configured at Jenkins side
Reporter: madriman madriman
Assignee: Joe Hansche
Priority: Blocker

 [confluence] Uploading attachments to Confluence page: 
 http://confluence.xxx.com/display/SOFTRELEASE/Home
 ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher 
 aborted due to exception
 java.lang.NullPointerException
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.findArtifacts(ConfluencePublisher.java:402)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performAttachments(ConfluencePublisher.java:170)
   at 
 com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:291)
   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627)
   at hudson.model.Run.run(Run.java:1446)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Finished: FAILURE

--
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-6400) schedule triggering not working sometimes

2012-04-27 Thread alextre...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162168#comment-162168
 ] 

Alex Trepca commented on JENKINS-6400:
--

Hello,

Bringing this back to life. I have the same issue, os: CentOS 5.7, Jenkins: 
1.443, master + 3 build slaves (which are shared with another Jenkins instance).

- job is scheduled to run 55 9,11,16 * * * and last run 'started by timer' 
was 'Apr 24, 2012 4:55:55 PM'
- job is scheduled to run 30 8 * * * and last run 'started by timer' was 'Apr 
24, 2012 8:30:56 AM'

I also created a test job which only echoes a text, scheduled to run */5 * * * 
* and so far it ran:

  #8Apr 27, 2012 3:30:55 PM 
  #7Apr 27, 2012 3:16:48 PM 
  #6Apr 27, 2012 3:00:38 PM 
  #5Apr 27, 2012 2:53:05 PM 
  #4Apr 27, 2012 2:43:07 PM 
  #3Apr 27, 2012 2:43:01 PM 
  #2Apr 27, 2012 2:31:28 PM 
  #1Apr 27, 2012 2:23:06 PM

Which is not */5 at all.

Also, the server has been restarted yesterday evening (because of other 
reasons), and the problem persists.

What might be causing this?

Thank you,
Alex

 schedule triggering not working sometimes
 -

 Key: JENKINS-6400
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6400
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Windows Server
Reporter: deccico
 Attachments: memory_used.JPG, Thread dump [Hudson].htm


 Hi, I have a Hudson master with three or four slaves and a bunch of critical 
 tasks running nightly.
 Last night any scheduled job was triggered, and triggering of jobs stop 
 working at all during the day. 
 There was not any error or warning in the logs, and the service was not 
 killed or restarted during this problem. 
 I tried restarting the Hudson service and see if a job with a * * * * * 
 scheduling was launched, with no luck.
 Finally I got luck by restarting the machine.
 How can i contribute solving this bug or at least adding logging info?
 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-4838) Subrepo support

2012-04-27 Thread jenk...@g.zazu.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162169#comment-162169
 ] 

Glenn Zazulia commented on JENKINS-4838:


Any activity on this?  We use hg subrepos, and I've got a partial work-around 
that allows us to include the subrepo changes on the jenkins Changes screens, 
but it doesn't work for the email notifications:

Our build script runs a similar hg incoming command to the one that the 
jenkins mercurial plug-in already runs for the top level hg repo, and it 
modifies/augments the jenkins changelog.xml file in the builds directory with 
the additional changes for each subrepo.

Here's a partial snippet from that script:
{quote}
{noformat}
TEMPLATE=changeset node='{node}' author='{author|xmlescape}' rev='{rev}' 
date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
 

{
grep -v '/changesets' $CHANGELOG

# Run the hg incoming report to pick up the changes for each project.
# (The main/parent project changelog is already captured by jenkins.)
for PROJECT in $@; do
   hg -R $PROJECT incoming --quiet --template $TEMPLATE
done

echo /changesets
}  $CHANGELOG.new   mv $CHANGELOG.new $CHANGELOG
{noformat}
{quote}

The script then proceeds to update the workspace with the incoming subrepo 
changesets and complete the build.  The final kludge to get jenkins to see the 
modified changelog.xml file is to trigger a jenkins reload.

It would be better to get this functionality into the mercurial plugin and 
avoid needing to do that kludge, which would likely also allow the added 
changes to be included with the build notification emails.  I haven't yet 
delved into jenkins plug-in module development but might look into it for this.

 Subrepo support
 ---

 Key: JENKINS-4838
 URL: https://issues.jenkins-ci.org/browse/JENKINS-4838
 Project: Jenkins
  Issue Type: New Feature
  Components: mercurial
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: jglick
Assignee: jglick

 In addition to supporting the Forest extension, it would be good to support 
 the
 new subrepo system in Hg 1.3+.

--
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-4838) Subrepo support

2012-04-27 Thread jenk...@g.zazu.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162169#comment-162169
 ] 

GlennZ edited comment on JENKINS-4838 at 4/27/12 8:47 PM:
--

Any activity on this?  We use hg subrepos, and I've got a partial work-around 
that allows us to include the subrepo changes on the jenkins Changes screens, 
but it doesn't work for the email notifications:

Our build script runs a similar hg incoming command to the one that the 
jenkins mercurial plug-in already runs for the top level hg repo, and it 
modifies/augments the jenkins changelog.xml file in the builds directory with 
the additional changes for each subrepo.

Here's a partial snippet from that script:
{quote}
{noformat}
TEMPLATE=changeset node='{node}' author='{author|xmlescape}' rev='{rev}' 
date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
 

{
grep -v '/changesets' $CHANGELOG

# Run the hg incoming report to pick up the changes for each project.
# (The main/parent project changelog is already captured by jenkins.)
for PROJECT in $@; do
   hg -R $PROJECT incoming --quiet --template $TEMPLATE
done

echo /changesets
}  $CHANGELOG.new   mv $CHANGELOG.new $CHANGELOG
{noformat}
{quote}

Note that the above hg in will include all changesets up to tip since the 
last build.  To more generally support the .hgsubstate file, the hg in should 
include -r $rev, where $rev is set from the entry in .hgsubstate.

The build script then proceeds to update the workspace with the incoming 
subrepo changesets and complete the build.  The final kludge to get jenkins to 
see the modified changelog.xml file is to trigger a jenkins reload.

It would be better to get this functionality into the mercurial plugin and 
avoid needing to do that kludge, which would likely also allow the added 
changes to be included with the build notification emails.  I haven't yet 
delved into jenkins plug-in module development but might look into it for this.

  was (Author: gzilla):
Any activity on this?  We use hg subrepos, and I've got a partial 
work-around that allows us to include the subrepo changes on the jenkins 
Changes screens, but it doesn't work for the email notifications:

Our build script runs a similar hg incoming command to the one that the 
jenkins mercurial plug-in already runs for the top level hg repo, and it 
modifies/augments the jenkins changelog.xml file in the builds directory with 
the additional changes for each subrepo.

Here's a partial snippet from that script:
{quote}
{noformat}
TEMPLATE=changeset node='{node}' author='{author|xmlescape}' rev='{rev}' 
date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
 

{
grep -v '/changesets' $CHANGELOG

# Run the hg incoming report to pick up the changes for each project.
# (The main/parent project changelog is already captured by jenkins.)
for PROJECT in $@; do
   hg -R $PROJECT incoming --quiet --template $TEMPLATE
done

echo /changesets
}  $CHANGELOG.new   mv $CHANGELOG.new $CHANGELOG
{noformat}
{quote}

The script then proceeds to update the workspace with the incoming subrepo 
changesets and complete the build.  The final kludge to get jenkins to see the 
modified changelog.xml file is to trigger a jenkins reload.

It would be better to get this functionality into the mercurial plugin and 
avoid needing to do that kludge, which would likely also allow the added 
changes to be included with the build notification emails.  I haven't yet 
delved into jenkins plug-in module development but might look into it for this.
  
 Subrepo support
 ---

 Key: JENKINS-4838
 URL: https://issues.jenkins-ci.org/browse/JENKINS-4838
 Project: Jenkins
  Issue Type: New Feature
  Components: mercurial
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: jglick
Assignee: jglick

 In addition to supporting the Forest extension, it would be good to support 
 the
 new subrepo system in Hg 1.3+.

--
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-13048) dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'

2012-04-27 Thread fred...@hotmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162170#comment-162170
 ] 

Fred G commented on JENKINS-13048:
--

Pull request: https://github.com/jenkinsci/dropdown-viewstabbar-plugin/pull/2


 dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'
 

 Key: JENKINS-13048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13048
 Project: Jenkins
  Issue Type: Bug
  Components: dropdown-viewstabbar
Affects Versions: current
 Environment: jenkins 1.454
Reporter: Bruno Marti
Assignee: jieryn
 Attachments: dropdown-viewstabbar.jpg


 selected checkbox 'Show Job Counts' for Views Tab Bar in general configure 
 screen wont be saved. It is always un-checked.

--
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-13048) dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'

2012-04-27 Thread fred...@hotmail.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on JENKINS-13048 started by jieryn.

 dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'
 

 Key: JENKINS-13048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13048
 Project: Jenkins
  Issue Type: Bug
  Components: dropdown-viewstabbar
Affects Versions: current
 Environment: jenkins 1.454
Reporter: Bruno Marti
Assignee: jieryn
 Attachments: dropdown-viewstabbar.jpg


 selected checkbox 'Show Job Counts' for Views Tab Bar in general configure 
 screen wont be saved. It is always un-checked.

--
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-10555) Extended choice plugin does not work with remote builds

2012-04-27 Thread mel...@mdekort.nl (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-10555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Melvyn de Kort updated JENKINS-10555:
-

   Priority: Critical  (was: Major)
Component/s: extended-choice-parameter
 (was: plugin)

 Extended choice plugin does not work with remote builds
 ---

 Key: JENKINS-10555
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10555
 Project: Jenkins
  Issue Type: Bug
  Components: extended-choice-parameter
 Environment: Hudson 1.395, Jenkins 1.383 with Extended choice Plugin 
 0.4
Reporter: Danny Staple
Priority: Critical

 The extended choice plugin will fail when used with remote builds. The 
 parameter will not be recognised as being passed.
 In the plugin the following function is incorrect:
 {code()}
 public ParameterValue createValue(StaplerRequest request) {
String value[] = request.getParameterValues(getName());
if (value == null) {
return getDefaultParameterValue();
}
return null;
}
 {code}
 Note here that if the parameter is not set, it will set a default value. 
 Otherwise it will always return NULL when it should return the current value, 
 as something like a new ExtendedChoiceParameterValue.

--
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-9104) Visual studio builds started by Jenkins fail with Fatal error C1090 because mspdbsrv.exe gets killed

2012-04-27 Thread jenk...@mockies.de (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162171#comment-162171
 ] 

Christoph Vogtländer commented on JENKINS-9104:
---

I would not recommend setting the shutdown time to such a high value. 
mspdbsrv.exe tends to hang after some time because of handle leaks (at least 
the version shipped with Visual Studio 2005) causing the compiler to exit with 
error when trying to access pdb files. mspdbsrv process must be killed 
manually, then.

 Visual studio builds started by Jenkins fail with Fatal error C1090 because 
 mspdbsrv.exe gets killed
 --

 Key: JENKINS-9104
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9104
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Windows XP, using MSBuild or devenv.exe to build MS 
 Visual Studio Projects
Reporter: Christoph Vogtländer
Priority: Minor

 I run into errors when using a customized build system which uses Visual 
 Studio's devenv.exe under the hood to compile VisualStudio 2005 projects 
 (with VC++ compiler). When starting two parallel builds with Jenkins (on 
 different code base) the second job will always fail with Fatal error C1090: 
 PDB API call failed, error code '23' : '( in exactly the same second the 
 first job finishes processing. Running both jobs outside Jenkins does not 
 produce the error.
 This has also been reported for builds executed by MSBuild on the Jenkins 
 user mailing list [1].
 I analysed this issue thoroughly and can track the problem down to the usage 
 of mspdbsrv.exe. This program is automatically spawned when building a 
 VisualStudio project. All Visual Studio instances normally share one common 
 pdb-server which shutdown itself after a idle period (standard is 10 
 minutes). It ensures access to .pdb files is properly serialized in parallel 
 builds when multiple instances of the compiler try to access the same .pdb 
 file [2].
 I assume that Jenkins does a clean up of its build environment when a 
 automatically started job finishes (like as described at 
 http://wiki.jenkins-ci.org/display/JENKINS/Aborting+a+build). I checked 
 mspbsrv.exe with ProcessExplorer and the process indeed has a variable 
 JENKINS_COOKIE/HUDSON_COOKIE set in its environment if started through 
 Jenkins. Killing mspdbsrv.exe while projects are still connected will break 
 compilation. 
 Jenkins mustn't kill mspdbsrv.exe to be able to build more than one Visual 
 Studio project at the same time.
 --
 [1] 
 http://jenkins.361315.n4.nabble.com/MSBuild-fatal-errors-when-build-triggered-by-timer-td385181.html
 [2] 
 http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b1d1bceb-06b6-47ef-a0ea-23ea752e0c4f/

--
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-13637) Cannot release using M3

2012-04-27 Thread jgl...@java.net (JIRA)
jglick created JENKINS-13637:


 Summary: Cannot release using M3
 Key: JENKINS-13637
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13637
 Project: Jenkins
  Issue Type: Bug
  Components: plugin
 Environment: Ubuntu, JDK 6
Reporter: jglick


Given the {{mercurial}} plugin with parent 
{{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with {{1.461}}, 
Maven 3 {{mvn -B release:prepare}} fails with

{code}
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'Jenkins Mercurial plugin'...
Downloading: 
CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom
[WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is 
missing, no dependency information available
Downloading: 
CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5.310s
[INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012
[INFO] Final Memory: 10M/164M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on 
project mercurial: Execution default-cli of goal 
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to 
build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: 
Some problems were encountered while processing the POMs:
[ERROR] [ERROR] Unresolveable build extension: Plugin 
org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not 
be resolved: Could not find artifact 
org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) 
@: 1 problem was encountered while building the effective model for 
org.jenkins-ci.plugins:plugin:1.461
[ERROR] [ERROR] Unresolveable build extension: Plugin 
org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not 
be resolved: Could not find artifact 
org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @
{code}

Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again 
{{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any 
{{pluginRepository}} in which it might be found. (Nor does its own parent.)

Maven 2 succeeds in this case; apparently it does not care where the plugin 
came from. But Maven 3 as described in 
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
 does care.

--
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-13048) dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

SCM/JIRA link daemon resolved JENKINS-13048.


Resolution: Fixed

 dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'
 

 Key: JENKINS-13048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13048
 Project: Jenkins
  Issue Type: Bug
  Components: dropdown-viewstabbar
Affects Versions: current
 Environment: jenkins 1.454
Reporter: Bruno Marti
Assignee: jieryn
 Attachments: dropdown-viewstabbar.jpg


 selected checkbox 'Show Job Counts' for Views Tab Bar in general configure 
 screen wont be saved. It is always un-checked.

--
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-13048) dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162172#comment-162172
 ] 

SCM/JIRA link daemon commented on JENKINS-13048:


Code changed in jenkins
User: Fred G
Path:
 src/main/java/hudson/views/tabbar/DropDownViewsTabBar.java
 src/main/resources/hudson/views/tabbar/DropDownViewsTabBar/config.jelly
 src/main/resources/hudson/views/tabbar/DropDownViewsTabBar/viewTabs.jelly
http://jenkins-ci.org/commit/dropdown-viewstabbar-plugin/9c813f1f51d060d5daa64fb72fe9f41882e73d03
Log:
  [FIXED JENKINS-13048] Cannot save checkbox 'Show Job Counts', moved
checkbox label to the right for a more consistent layout




 dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'
 

 Key: JENKINS-13048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13048
 Project: Jenkins
  Issue Type: Bug
  Components: dropdown-viewstabbar
Affects Versions: current
 Environment: jenkins 1.454
Reporter: Bruno Marti
Assignee: jieryn
 Attachments: dropdown-viewstabbar.jpg


 selected checkbox 'Show Job Counts' for Views Tab Bar in general configure 
 screen wont be saved. It is always un-checked.

--
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-13048) dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'

2012-04-27 Thread jie...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162175#comment-162175
 ] 

jieryn commented on JENKINS-13048:
--

Released in v1.5 @ 
http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/dropdown-viewstabbar-plugin/1.5/

Thank you Fred!

 dropdown-viewstabbar: cannot save checkbox 'Show Job Counts'
 

 Key: JENKINS-13048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13048
 Project: Jenkins
  Issue Type: Bug
  Components: dropdown-viewstabbar
Affects Versions: current
 Environment: jenkins 1.454
Reporter: Bruno Marti
Assignee: jieryn
 Attachments: dropdown-viewstabbar.jpg


 selected checkbox 'Show Job Counts' for Views Tab Bar in general configure 
 screen wont be saved. It is always un-checked.

--
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-12361) Modules with directory separators don't work on Windows

2012-04-27 Thread scm_issue_l...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162177#comment-162177
 ] 

SCM/JIRA link daemon commented on JENKINS-12361:


Code changed in jenkins
User: jglick
Path:
 src/main/java/hudson/plugins/mercurial/MercurialSCM.java
 src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
http://jenkins-ci.org/commit/mercurial-plugin/ab0aa6c46e85a80f8ee3b5a7db6e680ade14fecd
Log:
  Merge pull request #18 from kmbell/jenkins-12361

Fix for JENKINS-12361




 Modules with directory separators don't work on Windows
 ---

 Key: JENKINS-12361
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12361
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
 Environment: Windows
Reporter: Kevin Bell
Assignee: Kevin Bell
Priority: Minor
  Labels: plugin, windows

 Specifying a module such as 'src/main' does not work on windows.
 Internally, the mercurial plugin converts the module paths to have unix '/' 
 separators, but paths returned by 'hg status' have '\' separators, so the 
 String.startsWith(...) test in MercurialSCM.dependentChanges() always returns 
 false.

--
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-13531) Plugin replacing + with in configuration strings when plugin is instantiated.

2012-04-27 Thread glimb...@gmail.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

glimberg updated JENKINS-13531:
---

Component/s: plugin

 Plugin replacing + with   in configuration strings when plugin is 
 instantiated.
 ---

 Key: JENKINS-13531
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13531
 Project: Jenkins
  Issue Type: Bug
  Components: core, plugin
Affects Versions: current
 Environment: RedHat Linux and Mac OS X Lion
Reporter: glimberg
  Labels: configuration, plugins, url-encoding

 I've been experimenting with the Amazon S3 Publisher plugin in Jenkins 1.460 
 in preparation for starting to use S3 for artifact storage  program 
 distribution at work. I kept getting errors with the S3 plugin, however, 
 stating Can't connect to S3 service: The request signature we calculated 
 does not match the signature you provided. Check your key and signing 
 method.  
 The Access  Secret Keys were correct and being stored correctly in the 
 hudson.plugins.s3.S3BucketPublisher.xml configuration file.  I added some 
 logging to the plugin to discover that in 
 S3BucketPublisher.DescriptorImpl.doLoginCheck(), the secretKey element of 
 the StaplerRequest parameter was being returned incorrectly.  There's a + 
 character in the secret key.  The plus was being turn into a space ( ), 
 thus the plugin is unable to connect to S3.
 The issue first appears with Jenkins  the S3 Publisher plugin in Jenkins 
 1.455 and continues through 1.460.  Versions 1.454 and prior behave as 
 expected.  The + in the secret key is retained and connection to S3 is 
 possible. Nothing has changed in the S3 plugin in that time period, so the 
 issue must be somewhere inside Jenkins itself.  Unfortunately, I'm rather 
 unfamiliar with the Jenkins architecture and plugin architecture an am unable 
 to trace the issue further down the chain than that.
 To recreate the issue:
 1) get the S3 plugin (https://github.com/jenkinsci/s3-plugin)
 2) set the jenkins version on line 6 of pom.xml to 1.455 or greater.
 3) in Configure System, add an S3 profile.  Valid or not does not matter.  
 Make sure there's a + in the secret key or the access key field.
 4) Set a breakpoint, or print out the value of req.getParameter(secretKey) 
 in S3BucketPublisher.DescriptorImpl.doLoginCheck().  See that the + has 
 been turned into a  .  
 The strange thing is that if you look in the actual form fields secretKey or 
 accessKey, the + will be in there correctly. Somehow it's not getting to the 
 actual plugin code as a +, though.
 Workarounds:
 None known at this time.  
 I attempted to replace the + with its URLEncoded form %2B in the 
 configuration file, but %2B comes through instead of being decoded into a +.
 The only hack I have to get it working for us at the office for the time 
 being is to replace all instances of   in the secretKey with +.  Not a 
 good solution.

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