date:20120421


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

gbois updated JENKINS-10651:


Component/s: dashboard-view
 (was: cppcheck)

Change component to dashboard-view.
In my opinion, cppcheck plugin should not have any dependency to dashboard-view.
It has to be independent.
Therefore, I change the component issue.

 Add cppcheck to Dashboard View
 

 Key: JENKINS-10651
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10651
 Project: Jenkins
  Issue Type: New Feature
  Components: dashboard-view
Reporter: keperry
Assignee: gbois
Priority: Minor

 It would be awesome if the cppcheck plugin could be added to the 
 https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View.  This is the only 
 plugin that I have right now that I can't get summary information for all my 
 projects in one place.  Please add to the dashboard view plugin in the future.

--
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-10368) Wrong image dimension for Cppcheck Results link on Dashboard


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

SCM/JIRA link daemon commented on JENKINS-10368:


Code changed in jenkins
User: Gregory Boissinot
Path:
 
src/main/java/org/jenkinsci/plugins/cppcheck/util/AbstractCppcheckProjectAction.java
http://jenkins-ci.org/commit/cppcheck-plugin/17d9731ff2990fafe1e4ca04638a34d30625192a
Log:
  Fix JENKINS-10368




 Wrong image dimension for Cppcheck Results link on Dashboard 
 -

 Key: JENKINS-10368
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10368
 Project: Jenkins
  Issue Type: Bug
  Components: cppcheck
Affects Versions: current
 Environment: OS: Linux, openSUSE;
 OS version: 11.4;
 DE: LXDE;
 WebBrowser: Mozilla Firefox 4.+.
Reporter: Sergey Piatakov
Assignee: gbois
Priority: Trivial
 Attachments: cppcheck_plugin_version.png, 
 wrong_jenkins_image_on_cppcheck_build_detailed_page.png, 
 wrong_jenkins_image_on_cppcheck_dashboard.png, 
 wrong_jenkins_image_on_cppcheck_link.png


 Wrong image for Cppcheck Results link on Dashboard.
 Using file: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-24.png
 instead of: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-48.png

--
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-13217) Build Status page continues to show flashing building icons after build completion


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

dogfood commented on JENKINS-13217:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13217] Build Status page continues to show flashing 
building (Revision eb3e288d6e761109c20cf479c80dfb4c69801dbe)

 Result = SUCCESS
Seiji Sogabe : 
[eb3e288d6e761109c20cf479c80dfb4c69801dbe|https://github.com/jenkinsci/jenkins/commit/eb3e288d6e761109c20cf479c80dfb4c69801dbe]
Files : 
* core/src/main/resources/lib/hudson/buildCaption.jelly
* changelog.html


 Build Status page continues to show flashing building icons after build 
 completion
 

 Key: JENKINS-13217
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13217
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Jenkins 1.456/ Ubuntu 11.10
Reporter: Richard Mortimer
Assignee: Richard Mortimer
Priority: Minor

 The main build status page shows a 48x48 icon representing the build status. 
 If you visit the page during the build this shows a flashing build in 
 progress icon. However when the build stops the build in progress icon 
 continues to be displayed.
 This is due to browser caching behaviour. For example the recent build at the 
 following URL
 http://ci.jenkins-ci.org/job/tools_maven-hpi-plugin-maven-2.x/40/
 During the build the relevant markup was
 {code}
 img height=48 alt=In progress width=48 src=buildStatus tooltip=In 
 progress /
 Build #40
 (23-Mar-2012 01:18:30)
 {code}
 The request for buildStatus returned a HTTP 302 redirect to
 {code}
 Location:http://ci.jenkins-ci.org/images/48x48/blue_anime.gif
 {code}
 The combination of a 302 redirect and caching headers in the gif cause the 
 browser to not re-request buildStatus within the same browser session.
 http://ci.jenkins-ci.org/job/tools_maven-hpi-plugin-maven-2.x/40/buildStatus
 Note this is unrelated to the recent changes for caching of images etc. I 
 have noticed this in the past but have not had time to investigate before now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13319) Change icon for repeatableDeleteButton and show tooltip on it


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

dogfood commented on JENKINS-13319:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 
 Result = SUCCESS

 Change icon for repeatableDeleteButton and show tooltip on it
 -

 Key: JENKINS-13319
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13319
 Project: Jenkins
  Issue Type: Improvement
  Components: ui-changes
Reporter: OHTAKE Tomohiro
Assignee: OHTAKE Tomohiro
Priority: Minor

 Currently icon for repeatableDeleteButton is edit-delete.png. [1]
 Change it to user-trash.png. [3]
 Discussions: (written in Japanese)
 [1] https://twitter.com/#!/ohtaket/status/186631033582657538
 [2] https://twitter.com/#!/kohsukekawa/status/186913466391597056
 [3] https://twitter.com/#!/ohtaket/status/186977316025540609
 [4] https://twitter.com/#!/kohsukekawa/status/186978692772278272
 [5] https://twitter.com/#!/ohtaket/status/186983488975679488
 [6] https://twitter.com/#!/kohsukekawa/status/186983938441494529

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449


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

dogfood commented on JENKINS-12037:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-12037] CLI - I/O error in channel Chunked connection 
(Revision ea1b80aebe85a9414d5befd58e976d85818a258d)

 Result = SUCCESS
richm : 
[ea1b80aebe85a9414d5befd58e976d85818a258d|https://github.com/jenkinsci/jenkins/commit/ea1b80aebe85a9414d5befd58e976d85818a258d]
Files : 
* cli/src/main/java/hudson/cli/CLI.java
* changelog.html


 CLI - I/O error in channel Chunked connection/Unexpected termination of the 
 channel - still occurring in Jenkins 1.449
 --

 Key: JENKINS-12037
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12037
 Project: Jenkins
  Issue Type: Bug
  Components: cli
 Environment: * Running on SLES9 Linux server with 4 CPUs and plenty 
 of diskspace.
 * Tomcat 7.0.22
 * JDK 1.6.0_14
 * Only ONE Master configuration - no slaves are configured
 * 3 Executors - (one less than the max number of CPUs) 
Reporter: mark streit
Priority: Critical
 Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip


 We reported an issue some time back that was also listed as fixed in Jenkins 
 1.441:
 Log:
 [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when 
 using jenkins-cli.jar
 Perhaps another bug should NOT be submitted so I have added the following 
 comments below the line to the original defect 11130 comments section in case 
 it can be reviewed/re-opened.
 We did NOT try to make any adjustments to the Tomcat configuration:
 Tomcat Connector connectionUploadTimeout
 but we are also now seeing the same problem with Winstone when at this same 
 1.441 level.  We did revert to the 1.438 version of the CLI (leaving the WAR 
 at 1.441 running in Winstone) and that is serving asthe current workaround.
 
 We have downloaded and installed the LATEST 1.441 release that lists the fix 
 for this problem. Currently we were running 1.438 on Winstone only (since 
 with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, 
 it worked OK so that was our workaround - while running 1.438).
 Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH 
 Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR 
 file in place running on Winstone, and reverted the CLI jar file back to the 
 1.438 version for now and that appears to work again with Winstone.
 Checked Manifest of CLI jar downloaded with the 1.441 WAR installation:
 Manifest-Version: 1.0
 Archiver-Version: Plexus Archiver
 Created-By: Apache Maven
 Built-By: kohsuke
 Build-Jdk: 1.6.0_26
 Main-Class: hudson.cli.CLI
 Jenkins-CLI-Version: 1.441
 Under Tomcat 7, we get this stacktrace:
 Started by command line
 [workspace] $ /bin/bash -xe 
 /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh
 + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar 
 -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p 
 SVN_PATH=trunk
 Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run
 SEVERE: I/O error in channel Chunked connection to 
 http://11.22.33.44:8082/jenkins/cli
 java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115)
 Caused by: java.io.EOFException
 at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109)
 Exception in thread main hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
 at hudson.remoting.Request.call(Request.java:149)
 at hudson.remoting.Channel.call(Channel.java:681)
 at 
 hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
 at $Proxy2.main(Unknown Source)
 at hudson.cli.CLI.execute(CLI.java:200)
 at hudson.cli.CLI._main(CLI.java:330)
 at hudson.cli.CLI.main(CLI.java:245)
 Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 at hudson.remoting.Request.abort(Request.java:273)
 at hudson.remoting.Channel.terminate(Channel.java:732)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139)

[JIRA] (JENKINS-13389) Move View as plain text link on console output page from top right to the sidepanel.


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

dogfood commented on JENKINS-13389:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13389] Moved View as plain text link on console output 
page from top right to (Revision 7681ab09828251640d2ca1508eef1027fb8afa9c)

 Result = SUCCESS
Fred G : 
[7681ab09828251640d2ca1508eef1027fb8afa9c|https://github.com/jenkinsci/jenkins/commit/7681ab09828251640d2ca1508eef1027fb8afa9c]
Files : 
* core/src/main/resources/hudson/model/AbstractBuild/tasks_da.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_zh_TW.properties
* core/src/main/resources/hudson/model/Run/console_sv_SE.properties
* core/src/main/resources/hudson/model/Run/console_pl.properties
* core/src/main/resources/hudson/model/Run/console_sk.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_lt.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_pt_PT.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_bg.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_is.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_el.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_zh_CN.properties
* core/src/main/resources/hudson/model/Run/console.jelly
* core/src/main/resources/hudson/model/Run/console_ro.properties
* core/src/main/resources/hudson/model/Run/console_fi.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_ko.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_ca.properties
* core/src/main/resources/hudson/model/Run/console_nb_NO.properties
* core/src/main/resources/hudson/model/Run/console_tr.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_cs.properties
* core/src/main/resources/hudson/model/Run/console_he.properties
* core/src/main/resources/hudson/model/Run/console_zh_TW.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_lv.properties
* core/src/main/resources/hudson/model/Run/console_it.properties
* core/src/main/resources/hudson/model/Run/console_hu.properties
* core/src/main/resources/hudson/model/Run/console_es.properties
* core/src/main/resources/hudson/model/Run/console_cs.properties
* core/src/main/resources/hudson/model/Run/console_pt_PT.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_pl.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_hi_IN.properties
* core/src/main/resources/hudson/model/Run/console_de.properties
* core/src/main/resources/hudson/model/Run/console_pt_BR.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_hu.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_de.properties
* core/src/main/resources/hudson/model/Run/console_eo.properties
* core/src/main/resources/hudson/model/Run/console_is.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_sv_SE.properties
* core/src/main/resources/hudson/model/Run/console_nl.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_he.properties
* core/src/main/resources/hudson/model/Run/console_el.properties
* core/src/main/resources/hudson/model/Run/console_fr.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_ja.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_es.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_ru.properties
* core/src/main/resources/hudson/model/Run/console_ru.properties
* core/src/main/resources/hudson/model/Run/console_lt.properties
* core/src/main/resources/hudson/model/Run/console_ja.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_pt_BR.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_ro.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_it.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_uk.properties
* core/src/main/resources/hudson/model/Run/console_hi_IN.properties
* core/src/main/resources/hudson/model/Run/console_uk.properties
* core/src/main/resources/hudson/model/Run/console_ca.properties
* core/src/main/resources/hudson/model/Run/console_lv.properties
* core/src/main/resources/hudson/model/Run/console_da.properties
* core/src/main/resources/hudson/model/Run/console_ko.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_nb_NO.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_eo.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_fi.properties
* core/src/main/resources/hudson/model/Run/console_bg.properties
* core/src/main/resources/hudson/model/AbstractBuild/tasks_tr.properties
*

[JIRA] (JENKINS-12302) Remote call on CLI channel from [ip] failed


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

dogfood commented on JENKINS-12302:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [JENKINS-12302] (Revision 7110ddb7d2a2f141a6887ffe352526db91046867)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[7110ddb7d2a2f141a6887ffe352526db91046867|https://github.com/jenkinsci/jenkins/commit/7110ddb7d2a2f141a6887ffe352526db91046867]
Files : 
* core/src/main/java/hudson/cli/CLICommand.java


 Remote call on CLI channel from [ip] failed
 ---

 Key: JENKINS-12302
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12302
 Project: Jenkins
  Issue Type: Bug
  Components: cli, groovy
Affects Versions: current
 Environment: Jenkins 1.446, Linux CentOS
Reporter: Markus Hjerto
Assignee: vjuranek

 I've had a KillStuckPolling.groovy job running for about 6 months without 
 problems, but on January 4th it stopped working with the below stack trace. 
 This matches with the release of Jenkins 1.446, which is currently installed. 
 I have tried to restart the server without any effect.
 {noformat}
 Killing all stuck SCM polls using ~/bin/KillStuckPolling.groovy
 log4j:WARN No appenders could be found for logger 
 (org.apache.commons.beanutils.converters.BooleanConverter).
 log4j:WARN Please initialize the log4j system properly.
 java.io.IOException: Remote call on CLI channel from /[ip] failed
   at hudson.remoting.Channel.call(Channel.java:690)
   at hudson.cli.GroovyCommand.loadScript(GroovyCommand.java:106)
   at hudson.cli.GroovyCommand.run(GroovyCommand.java:93)
   at hudson.cli.CLICommand.main(CLICommand.java:205)
   at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:66)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
 hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
   at 
 hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
   at 
 hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
   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 java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
   at java.util.concurrent.FutureTask.run(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
 Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)
 Caused by: java.lang.ExceptionInInitializerError
   at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
   at java.io.ObjectStreamClass.computeDefaultSUID(Unknown Source)
   at java.io.ObjectStreamClass.access$100(Unknown Source)
   at java.io.ObjectStreamClass$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.io.ObjectStreamClass.getSerialVersionUID(Unknown Source)
   at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
   at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
   at java.io.ObjectInputStream.readClassDesc(Unknown Source)
   at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
   at java.io.ObjectInputStream.readObject0(Unknown Source)
   at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
   at java.io.ObjectInputStream.readSerialData(Unknown Source)
   at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
   at java.io.ObjectInputStream.readObject0(Unknown Source)
   at java.io.ObjectInputStream.readObject(Unknown Source)
   at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
   at hudson.remoting.UserRequest.perform(UserRequest.java:98)
   ... 8 more
 Caused by: java.lang.NullPointerException
   at hudson.cli.CLICommand.clinit(CLICommand.java:448)
   ... 26 more
 Build step 'Execute shell' marked build as failure
 {noformat}
 The groovy script is as follows:
 {code:title=KillStuckPolling.groovy|borderStyle=solid}
  Thread.getAllStackTraces().keySet().each() { 
item -
println Checking item + item.getName();
if (item.getName().contains(SCM polling)

[JIRA] (JENKINS-13416) On demand slave provisioning is starting all available slaves


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

dogfood commented on JENKINS-13416:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13416] On demand slave provisioning is starting all 
available slaves (Revision 5a32eca331bf1d5652ab908c356f0ed64de82c6f)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[5a32eca331bf1d5652ab908c356f0ed64de82c6f|https://github.com/jenkinsci/jenkins/commit/5a32eca331bf1d5652ab908c356f0ed64de82c6f]
Files : 
* core/src/main/java/hudson/slaves/RetentionStrategy.java


 On demand slave provisioning is starting all available slaves
 -

 Key: JENKINS-13416
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13416
 Project: Jenkins
  Issue Type: Bug
  Components: slave-setup
Affects Versions: current
Reporter: Bruno Meneguello
Assignee: Kohsuke Kawaguchi
Priority: Minor
 Attachments: jenkins-1.459.diff


 I'm using on demand slaves (on amazon) started by a shell script. When 
 starting a job with all slaves disconnected, all my slaves are started 
 together.
 When in debug, I'd noticed that RetentionStrategy Demand is testing 
 Computer.getDemandStartMilliseconds() to connect the slave, but all slaves 
 (that 'll take some time to wake up) pass in test.
 Shouldn't this strategy take in account if there are executor enough and 
 nodes starting?
 I,ve made a change in RetentionStrategy that solves the problem. Anyone see 
 any problem with this 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

[JIRA] (JENKINS-13387) Convert Delete this build buttons into links in the sidepanel


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

dogfood commented on JENKINS-13387:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13387] Converted Delete this build buttons into links in 
the sidepanel, added (Revision be88e0120fef6d5837ef9adf9b7803cbdde88b30)

 Result = SUCCESS
Fred G : 
[be88e0120fef6d5837ef9adf9b7803cbdde88b30|https://github.com/jenkinsci/jenkins/commit/be88e0120fef6d5837ef9adf9b7803cbdde88b30]
Files : 
* core/src/main/resources/hudson/matrix/MatrixBuild/delete_de.properties
* core/src/main/resources/hudson/model/Run/delete.jelly
* core/src/main/resources/hudson/model/AbstractBuild/index.jelly
* core/src/main/resources/hudson/matrix/MatrixBuild/delete_ja.properties
* core/src/main/resources/hudson/model/AbstractBuild/sidepanel.jelly
* core/src/main/resources/hudson/matrix/MatrixBuild/delete.jelly
* 
core/src/main/resources/hudson/matrix/MatrixBuild/confirmDeleteAll_de.properties
* core/src/main/resources/hudson/model/Run/delete.properties


 Convert Delete this build buttons into links in the sidepanel
 ---

 Key: JENKINS-13387
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13387
 Project: Jenkins
  Issue Type: Improvement
  Components: gui, ui-changes
Reporter: Fred G
Assignee: Fred G
  Labels: gui
 Attachments: DeleteBuildButtons_MatrixBuild.png, 
 DeleteBuildButtons_MatrixConfig.png, DeleteBuildLinks_MatrixBuild.png, 
 DeleteBuildLinks_MatrixConfig.png


 The Delete this build buttons on build pages and also the Delete this 
 build and all configurations of this build buttons on matrix build pages
 should be converted to links in the sidepanel of the respective pages (see 
 Screenshots).
 This simplifies the user experience of deleting an object (see the Delete 
 Project link in the sidepanel of project pages).
 Having the links in the sidepanel also makes them accessible through the 
 newly added context menus that came with the breadcrumbs.
 Recent discussion about this topic:
 https://github.com/jenkinsci/jenkins/pull/403

--
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-13238) Loading All Build History Fails


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

dogfood commented on JENKINS-13238:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13238] Loading All Build History Fails (Revision 
a45ecf45ee8571aae7a0273784971afeeefb6e3c)

 Result = SUCCESS
Seiji Sogabe : 
[a45ecf45ee8571aae7a0273784971afeeefb6e3c|https://github.com/jenkinsci/jenkins/commit/a45ecf45ee8571aae7a0273784971afeeefb6e3c]
Files : 
* core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly


 Loading All Build History Fails
 ---

 Key: JENKINS-13238
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13238
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: linux, jenkins 1.456
Reporter: Spencer Oliver
Assignee: sogabe

 seems after the update from 1.455 to 1.456 causes an issue where pressing 
 'More' to expand the job Build History now fails with a 404.
 Calling the build history directly also causes the 404, eg.
 http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/
 For info rolling back to 1.455 cures the problem.
 tested 1.457 and issue still present.
 jenkins own server also shows the issue:
 http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/

--
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-13448) Guice injector failure can cause failure of whole Jenkins


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

dogfood commented on JENKINS-13448:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13448] Added additional checks if Guice will be able to 
create injector to exclude missing extension poins. (Revision 
6788f82a2c9f8e3580440913c2d39f1d1dc3ad70)

 Result = SUCCESS
Vojtech Juranek : 
[6788f82a2c9f8e3580440913c2d39f1d1dc3ad70|https://github.com/jenkinsci/jenkins/commit/6788f82a2c9f8e3580440913c2d39f1d1dc3ad70]
Files : 
* core/src/main/java/hudson/ExtensionFinder.java


 Guice injector failure can cause failure of whole Jenkins
 -

 Key: JENKINS-13448
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13448
 Project: Jenkins
  Issue Type: Bug
  Components: core
Reporter: vjuranek
Priority: Critical

 When Guice fails to create injector (e.g. because some extension point is 
 optional and therefore missing), it can break other plugins and eventually 
 crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381.

--
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-13505) Apply bootstrap style to hetero-list-add buttons


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

dogfood commented on JENKINS-13505:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13505] Apply bootstrap style to hetero-list-add buttons 
(Revision 84549d6220ac4ed0d7633e85eb8aed2cc69d56ca)

 Result = SUCCESS
ohtake.tomohiro : 
[84549d6220ac4ed0d7633e85eb8aed2cc69d56ca|https://github.com/jenkinsci/jenkins/commit/84549d6220ac4ed0d7633e85eb8aed2cc69d56ca]
Files : 
* core/src/main/resources/lib/form/hetero-list.jelly
* war/src/main/webapp/scripts/hudson-behavior.js


 Apply bootstrap style to hetero-list-add buttons
 --

 Key: JENKINS-13505
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13505
 Project: Jenkins
  Issue Type: Improvement
  Components: ui-changes
Reporter: OHTAKE Tomohiro
Assignee: OHTAKE Tomohiro
Priority: Minor

 Most of the buttons have been converted from YUI to Bootstrap.
 But hetero-list-add buttons are still YUI.
 We should apply Bootstrap style to hetero-list-add buttons.
 An example of hetero-list-add is:
 {code}
 Add build step ▾
   Execute shell
   Invoke Ant
   ...
 {code}

--
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-12647) Jetty configuration causes locked files when running tests on Windows, which causes test failures


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

dogfood commented on JENKINS-12647:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-12647] (Revision 7ae303f88191a540491a21484316d63dff775e21)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[7ae303f88191a540491a21484316d63dff775e21|https://github.com/jenkinsci/jenkins/commit/7ae303f88191a540491a21484316d63dff775e21]
Files : 
* test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java


 Jetty configuration causes locked files when running tests on Windows, which 
 causes test failures
 -

 Key: JENKINS-12647
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12647
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Windows 7 x64
 Java 1.6
Reporter: Slide-O-Mix
Assignee: Kohsuke Kawaguchi
 Attachments: jenkins-12647.patch


 When running tests on either the token-macro plugin or email-ext plugin that 
 create temporary files for the tests, the tests fail with an exception that 
 says those temporary files were not able to be deleted. I believe this is 
 related to [1] which, in summary, says that Jetty locks static files on 
 Windows.
 [1] http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows

--
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-11538) Jenkins serves existing files regardless of security


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

dogfood commented on JENKINS-11538:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-11538] integrated Stapler 1.187 that contains the fix. 
(Revision 9acf12f7976bd97bfa125e4b715ae340be8c1715)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[9acf12f7976bd97bfa125e4b715ae340be8c1715|https://github.com/jenkinsci/jenkins/commit/9acf12f7976bd97bfa125e4b715ae340be8c1715]
Files : 
* core/pom.xml


 Jenkins serves existing files regardless of security
 

 Key: JENKINS-11538
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11538
 Project: Jenkins
  Issue Type: Bug
  Components: security, www
Affects Versions: current
 Environment: Jenkins 1.436, Windows 7 64-bit SP1, build-in Winstone 
 servlet engine 0.9.10
Reporter: Steve Betts
Priority: Critical

 an url of the form (note the dot): https:/server/WEB-INF./web.xml will 
 return the file, even with security turned on and the client unauthenticated. 
 As will any other url that references a valid filename with a '.' after the 
 first directory name, such as https://server/scripts./behavior.js.
 these behaviors are considered culnerabilites by our large corporation.
 http://xforce.iss.net/xforce/xfdb/9446
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1858

--
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-8043) Reload Configuration from Disk loses labels for swarm-clients


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

dogfood commented on JENKINS-8043:
--

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [Fixed JENKINS-8043] Reload Configuration from Disk broke swarm clients 
(Revision 24c31d138fe7b9ff14870b921220bdf709af20cc)

 Result = SUCCESS
Seiji Sogabe : 
[24c31d138fe7b9ff14870b921220bdf709af20cc|https://github.com/jenkinsci/jenkins/commit/24c31d138fe7b9ff14870b921220bdf709af20cc]
Files : 
* core/src/main/java/jenkins/model/Jenkins.java


 Reload Configuration from Disk loses labels for swarm-clients
 ---

 Key: JENKINS-8043
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8043
 Project: Jenkins
  Issue Type: Bug
  Components: swarm
Reporter: voorth
Assignee: abayer



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13129) Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup


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

dogfood commented on JENKINS-13129:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [Fixed JENKINS-13129] Updating built-in plugins doesn't work, the file 
doesn't get pinned and is overwritten on the next startup (Revision 
2453985ca5f4cb2c824466d132fe3658020b72fe)

 Result = SUCCESS
alexlehm : 
[2453985ca5f4cb2c824466d132fe3658020b72fe|https://github.com/jenkinsci/jenkins/commit/2453985ca5f4cb2c824466d132fe3658020b72fe]
Files : 
* test/src/test/java/hudson/PluginManagerTest2.java
* core/src/main/java/hudson/PluginManager.java


 Updating built-in plugins doesn't work, the file doesn't get pinned and is 
 overwritten on the next startup
 --

 Key: JENKINS-13129
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13129
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: jenkins 1.456, tomcat 7.0.25, java 1.6.0-31 running on 
 windows vista
Reporter: Alex Lehmann
Assignee: Alex Lehmann
Priority: Critical

 I still cannot update cvs or subversion plugins without manually creating a 
 .pinned file.
 When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file 
 is installed into the plugin dir, but no cvs.jpi.pinned file is created. When 
 restarting the tomcat server, the file is replaced by the 1.6 version from 
 the war directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-8663) Parsing of POM happens before SNAPSHOT-Parents are updated

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

dogfood commented on JENKINS-8663:
--

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
[FIXED JENKINS-8663] Flag -U is not used during the parsing step of a
(Revision 1421ca15d5a36706214476e613eeab789b9066df)

Result = SUCCESS
Vincent Latombe :
[1421ca15d5a36706214476e613eeab789b9066df|https://github.com/jenkinsci/jenkins/commit/1421ca15d5a36706214476e613eeab789b9066df]
Files :
* maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java
* maven-plugin/src/main/java/hudson/maven/MavenUtil.java
* changelog.html
* maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java

Parsing of POM happens before SNAPSHOT-Parents are updated
--

Key: JENKINS-8663
URL: https://issues.jenkins-ci.org/browse/JENKINS-8663
Project: Jenkins
Issue Type: Bug
Components: maven2
Affects Versions: current
Environment: Hudson 1.394
Reporter: Stephan Pauxberger
Priority: Blocker

Given the following constellation.
Project A 1.0-SNAPSHOT (POM only)
Project B 1.0-SNAPSHOT (Jar, has A as parent)
Both jobs use private Maven repositories.
Both projects have a separate job.
Change something in project A, commit. Job A builds and deploys to repository
Change something in project B that dependes on changes in project A. Commit.
Job B starts an resolves the POM using the old parent POM, potentially
leading to a broken build.
For example: B declares a dependency WITH a version. Now remove the version
from B and enter a dependencyManagement entry into A. Commit A, later B.
Result: B fails because pom validation has no valid version for the
dependency.
Only solution (since private repositories are used): Clean workspace of B via
Webinterface, the rebuild B.

[JIRA] (JENKINS-5784) Usage of kill in logrotate script is non-portable


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

dogfood commented on JENKINS-5784:
--

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-5784] (Revision 8fb2f5162e499b5c0c4dc8f88af761b7c490bc38)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[8fb2f5162e499b5c0c4dc8f88af761b7c490bc38|https://github.com/jenkinsci/jenkins/commit/8fb2f5162e499b5c0c4dc8f88af761b7c490bc38]
Files : 
* rpm/SOURCES/jenkins.logrotate
* changelog.html


 Usage of kill in logrotate script is non-portable
 -

 Key: JENKINS-5784
 URL: https://issues.jenkins-ci.org/browse/JENKINS-5784
 Project: Jenkins
  Issue Type: Bug
  Components: other
Reporter: rombert
 Attachments: hudson.logrotate.patch2010-10-20pdurbin, 
 jenkins-logrotate.patch


 The logrotate script uses 
 {code}kill -SIGALRM `cat /var/run/hudson.pid`{code}
 which works fine for the bash builtin, but fails for /bin/kill, which only 
 accepts 
 {code}usage: kill [ -s signal | -p ] [ -a ] pid ...
kill -l [ signal ]{code}
 on CentOS 5.
 Using kill -s SIGALRM would make both variants happy and increase portability.

--
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-13122) Last modification date of files in a zip are not the original timestamps


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

dogfood commented on JENKINS-13122:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13122] Last modification date of files in a zip are not the 
original timestamps (Revision 3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d)

 Result = SUCCESS
Seiji Sogabe : 
[3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d|https://github.com/jenkinsci/jenkins/commit/3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d]
Files : 
* core/src/main/java/hudson/util/io/ZipArchiver.java
* changelog.html


 Last modification date of files in a zip are not the original timestamps
 

 Key: JENKINS-13122
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13122
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Cees Bos
Assignee: sogabe

 When do have archiving for a build, then the files on the master have the 
 original timestamps of the file (same as on the slave).
 But when you download it in a zip with '(all files in zip)' then the last 
 modification date of file is the datetime of that moment, instead of original.
 We have a job which archives a number of logfiles. Normally you can order it 
 on datetime to get the last logfile, but when you download it in a zip 
 ordering is impossible.

--
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-12457) 'Age' column on 'Test Result' tab may show incorrect value when a test suite divided into multiple junit files


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

dogfood commented on JENKINS-12457:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 Revert [FIXED JENKINS-12457] 'Age' column on 'Test Result' tab may show 
incorrect value when a test suite divided into multiple junit files (Revision 
7fba652710e64f6dce00e2e186e77ee2a39bd445)
[Re-FIXED JENKINS-12457] 'Age' column on 'Test Result' tab may show incorrect 
value when a test suite divided into multiple junit files (Revision 
d9e87705e8d693bc9d028e1da8c614c0fb736cd3)

 Result = SUCCESS
Christoph Kutzinski : 
[7fba652710e64f6dce00e2e186e77ee2a39bd445|https://github.com/jenkinsci/jenkins/commit/7fba652710e64f6dce00e2e186e77ee2a39bd445]
Files : 
* core/src/test/resources/hudson/tasks/junit/eclipse-plugin-test-report.xml
* core/src/main/java/hudson/tasks/junit/TestResult.java
* core/src/main/java/hudson/tasks/junit/SuiteResult.java
* core/src/test/java/hudson/tasks/junit/TestResultTest.java
* core/src/main/java/hudson/tasks/junit/CaseResult.java

Christoph Kutzinski : 
[d9e87705e8d693bc9d028e1da8c614c0fb736cd3|https://github.com/jenkinsci/jenkins/commit/d9e87705e8d693bc9d028e1da8c614c0fb736cd3]
Files : 
* 
core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_b_duplicate.xml
* core/src/test/java/hudson/tasks/junit/TestResultTest.java
* changelog.html
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_b.xml
* core/src/main/java/hudson/tasks/junit/CaseResult.java
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_a2.xml
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_a1.xml
* core/src/main/java/hudson/tasks/junit/TestResult.java


 'Age' column on 'Test Result' tab may show incorrect value when a test suite 
 divided into multiple junit files
 --

 Key: JENKINS-12457
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12457
 Project: Jenkins
  Issue Type: Improvement
  Components: junit
Affects Versions: current
Reporter: Greg Temchenko
Assignee: kutzi

 Somebody described the problem a year ago here:
 http://jenkins.361315.n4.nabble.com/Problem-with-Age-column-on-Test-Results-tab-td3172208.html
 {quote}
 I have a problem with 'Age' column on 'Test Results' tab. For couple of my 
 tests, all the time this column has value equals '1', despite the fact that 
 those tests start failing earlier than one build ago. When I switch to 
 'History' tab, in 'Test Result' column there is a 'Regression' value for all 
 builds, and it should be 'Regression' value only for the first build and 
 'Failed' for next builds.
 {quote}
 For me this happens because I have many junit xmls that containing the same 
 test suite name.
 In this case hudson.tasks.junit.CaseResult.getPreviousResult() gets the only 
 last junit xml result and if it's not failed then the Age column won't be 
 calculated properly.

--
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-13105) allow j/k navigation for search results


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

dogfood commented on JENKINS-13105:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [JENKINS-13105] for keyboard shortcuts plugin, allow j/k navigation for 
search results (Revision 5a0f1aa3a4da962bf29ebca6a4556f1617045005)
changelog entry for JENKINS-13105 (Revision 
0414b057a14c2c74a32eeab182df532ca7d16673)

 Result = SUCCESS
Jesse Farinacci : 
[5a0f1aa3a4da962bf29ebca6a4556f1617045005|https://github.com/jenkinsci/jenkins/commit/5a0f1aa3a4da962bf29ebca6a4556f1617045005]
Files : 
* core/src/main/resources/hudson/search/Search/search-failed.jelly

Olivier Lamy : 
[0414b057a14c2c74a32eeab182df532ca7d16673|https://github.com/jenkinsci/jenkins/commit/0414b057a14c2c74a32eeab182df532ca7d16673]
Files : 
* changelog.html


 allow j/k navigation for search results
 ---

 Key: JENKINS-13105
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13105
 Project: Jenkins
  Issue Type: New Feature
  Components: keyboard-shortcuts
Reporter: jieryn
Assignee: jieryn

 e.g. results page for :: 
 http://ci.jenkins-ci.org/view/Plugins/search/?q=perforce

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue


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

dogfood commented on JENKINS-12994:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIX JENKINS-12994] Quiet period is blocking other jobs in queue (Revision 
394e9d6c0488fae6834d97a158a018abb31f3179)
Update changelog for JENKINS-12994 (Revision 
07b3f2cccb077df85617f2748f9b329528bc263b)

 Result = SUCCESS
Vincent Latombe : 
[394e9d6c0488fae6834d97a158a018abb31f3179|https://github.com/jenkinsci/jenkins/commit/394e9d6c0488fae6834d97a158a018abb31f3179]
Files : 
* core/src/main/java/hudson/model/Queue.java

Vincent Latombe : 
[07b3f2cccb077df85617f2748f9b329528bc263b|https://github.com/jenkinsci/jenkins/commit/07b3f2cccb077df85617f2748f9b329528bc263b]
Files : 
* changelog.html


 Quiet period is blocking other jobs in queue
 

 Key: JENKINS-12994
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12994
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: teetoivo
Priority: Critical

 Starting from version 1.452, a job in queue waiting for the quiet period to 
 pass is blocking all other jobs that have been queued after it.
 Example:
 # Job A has quiet period set to 10 seconds
 # Job B has quiet period set to 300 seconds
 # Job C has quiet period set to 100 seconds
 # Jobs get queued in A-B-C order.
 # Job A starts executing after 10 seconds
 # After 100 seconds, status of job C changes to pending - Waiting for next 
 available executor even if free executors are available
 # After 300 seconds both jobs B and C start executing
 This problem is hardly visible when short quiet periods are used but becomes 
 problematic with longer quiet periods or plugins like Naginator that will 
 increase the quiet period to hours if the builds fail enough.
 Version 1.451 is the last release where this problem isn't visible. From 
 public releases, at least 1.452 and 1.454 are affected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13165) Cloning workspace loses hidden files/directories


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

dogfood commented on JENKINS-13165:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [JENKINS-13165] Added a test to reproduce the problem to no avail. 
(Revision 2b5a24c9b0ec6c3f1feedde080aa3196f419ae40)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[2b5a24c9b0ec6c3f1feedde080aa3196f419ae40|https://github.com/jenkinsci/jenkins/commit/2b5a24c9b0ec6c3f1feedde080aa3196f419ae40]
Files : 
* test/src/test/java/hudson/FileSystemProvisionerTest.java


 Cloning workspace loses hidden files/directories
 

 Key: JENKINS-13165
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13165
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Linux
Reporter: owenmehegan
Assignee: Kohsuke Kawaguchi

 I upgraded to Jenkins 1.456 today, and now my jobs that use the Clone 
 Workspace plugin are having problems because the workspace tar.gz that is 
 created when the job completes no longer includes the .git directory. In 
 1.449, which I ended up downgrading back to, the default setting for files to 
 include always pulls that in. I've verified this by running tar -tzf on the 
 workspace.tar.gz; in 1.449 .git is there, in 1.456 it isn't. 
 I wasn't able to force Jenkins to include it either. I tried putting **/, 
 **/.git and other variations on that in the list of files to include, but 
 none of them seemed to work.

--
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-13454) Optimize the plugin manager


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

dogfood commented on JENKINS-13454:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13454] Optimize the plugin manager (Revision 
e465f7202e42b0cb196e98c2e21abedcb85e60d4)

 Result = SUCCESS
unknown : 
[e465f7202e42b0cb196e98c2e21abedcb85e60d4|https://github.com/jenkinsci/jenkins/commit/e465f7202e42b0cb196e98c2e21abedcb85e60d4]
Files : 
* core/src/main/java/hudson/model/UpdateSite.java


 Optimize the plugin manager
 ---

 Key: JENKINS-13454
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13454
 Project: Jenkins
  Issue Type: Improvement
  Components: update-center
 Environment: Jenkins 1.459, Oracle JDK 1.7, Windows XP
Reporter: evernat
Assignee: evernat
 Attachments: monitoring.png


 In Manage Jenkins, the plugin manager (aka update center) is rather slow. 
 Slow is about 3 to 6 seconds on my windows laptop.
 The http requests of the plugin manager are mostly the slowest of all, as can 
 be seen in the joined screenshot of the monitoring plugin.
 The screenshot also shows that those http requests have a high cpu usage.
 The cause of the issue is that for each plugin, the 
 UpdateSite.getPlugin(String) and getData() methods read and parse all the 
 plugins data from the updates/default.json file each time.
 So the more plugins are available, the slower it is.
 I will submit a pull request.

--
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-13476) Broken user experience when searching on /pluginManager/available


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

dogfood commented on JENKINS-13476:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-13476] added filter to the update center. (Revision 
26974746d68043825f02abbc0c8ab6200e8d465f)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[26974746d68043825f02abbc0c8ab6200e8d465f|https://github.com/jenkinsci/jenkins/commit/26974746d68043825f02abbc0c8ab6200e8d465f]
Files : 
* changelog.html


 Broken user experience when searching on /pluginManager/available
 -

 Key: JENKINS-13476
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13476
 Project: Jenkins
  Issue Type: Bug
  Components: ui-changes
Affects Versions: current
 Environment: Jenkins 1.460
Reporter: sebastian_bergmann
 Attachments: screenshot.png


 1. Browse to /pluginManager/available
 2. CTRL+F (Find in Mozilla Firefox)
 3. Enter Git, for instance
 4. Browser scrolls to the location of the search result
 5. Search result is hidden behind the Install ... / Download ... overlay

--
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-3681) Hide Empty Tabs (Views) in the GUI


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

dogfood commented on JENKINS-3681:
--

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 [FIXED JENKINS-3681] Added View.READ permission. (Revision 
85e13303f8cfbebeb7dab347fda8ccf4069070b6)

 Result = SUCCESS
Kohsuke Kawaguchi : 
[85e13303f8cfbebeb7dab347fda8ccf4069070b6|https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6]
Files : 
* core/src/main/java/hudson/model/ViewGroupMixIn.java
* core/src/main/resources/hudson/model/Messages.properties
* core/src/main/java/hudson/security/AuthorizationStrategy.java
* changelog.html
* core/src/main/java/hudson/model/View.java


 Hide Empty Tabs (Views) in the GUI
 --

 Key: JENKINS-3681
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3681
 Project: Jenkins
  Issue Type: Improvement
  Components: gui
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: rnell

 I'd like the ability to hide tabs that have no visible jobs.  We use Project
 Based Security to limit development access to only their projects.  I don't 
 like
 that developers can still see all tabs used by the other groups, even though
 they are empty due to the security settings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-13282) ui-changes breadcrumbs should stick to top

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

dogfood commented on JENKINS-13282:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]

Result = SUCCESS

ui-changes breadcrumbs should stick to top
--

Key: JENKINS-13282
URL: https://issues.jenkins-ci.org/browse/JENKINS-13282
Project: Jenkins
Issue Type: New Feature
Components: ui-changes
Reporter: OHTAKE Tomohiro
Assignee: OHTAKE Tomohiro

Comment by KK
http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/61d571f2be751121/659c24674d13542c?show_docid=659c24674d13542c
{quote}
- The menu of the top banner doesn't seem very useful to me. Right now it
always shows the same 4 things from the action menu of the top page, which is
probably not what you intended. But even if it changes per page, I think it'd
end up just repeating what's on the left.
- I liked our recent breadcrumb that sticks to the top of the page.
{quote}
I agree with him because:
- Jenkins pages are highly hierarchical. Breadcrumbs may become longer
especially when we use JUnit Test Result, Analysis Plugins and Nested View.
- The first item of the breadcumbs provides a link to root. I don't think
a.brand should be always visible.
- I seldom click USER_NAME | log out links.

[JIRA] (JENKINS-13185) Computer.getHostName() returns null when it is not


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

dogfood commented on JENKINS-13185:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_ui-changes_branch 
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
 Fix for JENKINS-13185: If there is a fallback host.name specified, it 
should return that and not null. (Revision 
3629aebce4ee0a432baefa9e95cdc31a316a1c78)
add changelog entry for [JENKINS-13185] (Revision 
196aadc61eefecf92fd78bd96b1c98f221e8a179)

 Result = SUCCESS
andrew : 
[3629aebce4ee0a432baefa9e95cdc31a316a1c78|https://github.com/jenkinsci/jenkins/commit/3629aebce4ee0a432baefa9e95cdc31a316a1c78]
Files : 
* core/src/main/java/hudson/model/Computer.java

Olivier Lamy : 
[196aadc61eefecf92fd78bd96b1c98f221e8a179|https://github.com/jenkinsci/jenkins/commit/196aadc61eefecf92fd78bd96b1c98f221e8a179]
Files : 
* changelog.html


 Computer.getHostName() returns null when it is not
 --

 Key: JENKINS-13185
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13185
 Project: Jenkins
  Issue Type: Patch
  Components: core
Affects Versions: current
Reporter: Andrew Stone
Priority: Minor
 Attachments: getHostName.patch


 The current version of Computer.getHostName() returns null even if the 
 fallback returns a value.

--
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-11114) Separate errors report on build report page by severity type.


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

SCM/JIRA link daemon commented on JENKINS-4:


Code changed in jenkins
User: Gregory Boissinot
Path:
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckSummary.java
 src/main/resources/org/jenkinsci/plugins/cppcheck/Messages.properties
http://jenkins-ci.org/commit/cppcheck-plugin/f637c8350d3525978e31290989075a1ca0ed061a
Log:
  Fix JENKINS-4


Compare: https://github.com/jenkinsci/cppcheck-plugin/compare/a605f92...f637c83



 Separate errors report on build report page by severity type.
 -

 Key: JENKINS-4
 URL: https://issues.jenkins-ci.org/browse/JENKINS-4
 Project: Jenkins
  Issue Type: Improvement
  Components: cppcheck
 Environment: Not important.
Reporter: Sergey Piatakov
Assignee: gbois
Priority: Minor
 Attachments: current_report.png, proposed_report.jpeg


 Separate errors report on build report page by severity type.

--
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-10880) Git plugin fails on remote Poll


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

dogfood commented on JENKINS-10880:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_main_trunk #1668|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1668/]
 [JENKINS-10880] output the job when polling fails (Revision 
7066daf3ee9d75d427918b068293e5b4ebbc98cd)

 Result = SUCCESS
mguenther : 
[7066daf3ee9d75d427918b068293e5b4ebbc98cd|https://github.com/jenkinsci/jenkins/commit/7066daf3ee9d75d427918b068293e5b4ebbc98cd]
Files : 
* core/src/main/java/hudson/triggers/SCMTrigger.java


 Git plugin fails on remote Poll
 ---

 Key: JENKINS-10880
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10880
 Project: Jenkins
  Issue Type: Bug
  Components: git
Affects Versions: current
Reporter: robertdw
Assignee: Kohsuke Kawaguchi
Priority: Minor

 If you enable remote polling in the Git Plugin, the project will never poll 
 successfully, and stops other projects polling as well.
 In GitSCM, requiresWorkspaceForPolling() returns false if remotePoll is 
 enabled.
 https://github.com/jenkinsci/git-plugin/blob/git-1.1.12/src/main/java/hudson/plugins/git/GitSCM.java#L582
 This mean that in the jenkins-core AbstractProject (at least on the LTS 
 branch), a null value is passed in for the workspace parameter to SCM.poll()
 https://github.com/jenkinsci/jenkins/blob/jenkins-1.409.1/core/src/main/java/hudson/model/AbstractProject.java#L1305
 This ends up in 'compareRemoteRevisionWith' back in GitSCM. At line 651, the 
 call to 'workingDirectory(workspace)' returns null - because null was passed 
 in as a param from AbstractProject. This means that at line 657, the call to 
 !!workingDirectory.exists() results in a null pointer.
 Suggested fix: remove the remotePoll, or make it require a workspace to do 
 the polling. 
 Stacktrace:
 Sep 2, 2011 2:41:50 PM hudson.triggers.SCMTrigger$Runner runPolling
 SEVERE: Failed to record SCM polling
 java.lang.NullPointerException
   at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:657)
   at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:354)
   at hudson.scm.SCM.poll(SCM.java:371)
   at hudson.model.AbstractProject.poll(AbstractProject.java:1305)
   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
   at hudson.triggers.SCMTrigger.run(SCMTrigger.java:103)
   at hudson.triggers.SCMTrigger.run(SCMTrigger.java:83)
   at hudson.triggers.Trigger$1.run(Trigger.java:229)
   at hudson.DependencyRunner.run(DependencyRunner.java:73)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)

--
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-13524) Validate project naming regex immediately


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

dogfood commented on JENKINS-13524:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[jenkins_main_trunk #1668|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1668/]
 [FIXED JENKINS-13524] Validate project naming regex immediately (Revision 
5587d13f58b14bffa9f77f7433358e14add9bcfa)

 Result = SUCCESS
Seiji Sogabe : 
[5587d13f58b14bffa9f77f7433358e14add9bcfa|https://github.com/jenkinsci/jenkins/commit/5587d13f58b14bffa9f77f7433358e14add9bcfa]
Files : 
* 
core/src/main/resources/jenkins/model/ProjectNamingStrategy/PatternProjectNamingStrategy/config.groovy
* core/src/main/resources/jenkins/model/Messages_ja.properties
* core/src/main/resources/jenkins/model/Messages.properties
* core/src/main/java/jenkins/model/ProjectNamingStrategy.java
* changelog.html


 Validate project naming regex immediately
 -

 Key: JENKINS-13524
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13524
 Project: Jenkins
  Issue Type: Improvement
  Components: core
Reporter: Ben Golding
Assignee: sogabe
Priority: Minor

 Manage Jenkins -- Restrict project naming -- Strategy: Pattern -- Name 
 Pattern: your regex
 When trying to save the configuration, the regex should be checked for 
 correctness (e.g. matching parens)
 Alternatively this could even be done in real time on the configuration page.
 [Workaround: any regex errors will appear - and need to be fixed immediately 
 - when you try to configure/create a job]

--
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-11114) Separate errors report on build report page by severity type.


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

gbois resolved JENKINS-4.
-

Resolution: Fixed

 Separate errors report on build report page by severity type.
 -

 Key: JENKINS-4
 URL: https://issues.jenkins-ci.org/browse/JENKINS-4
 Project: Jenkins
  Issue Type: Improvement
  Components: cppcheck
 Environment: Not important.
Reporter: Sergey Piatakov
Assignee: gbois
Priority: Minor
 Attachments: current_report.png, proposed_report.jpeg


 Separate errors report on build report page by severity type.

--
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-11716) Renaming a job does not rename the build record root dir, for a Jenkins instance configured with this feature

2012-04-21 Thread sdrot...@gmail.com (JIRA)

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

Steve Roth commented on JENKINS-11716:
--

This is still an issue with Jenkins v1.454.

Renaming a job does not rename the build record root dir, for a Jenkins
instance configured with this feature
-

Key: JENKINS-11716
URL: https://issues.jenkins-ci.org/browse/JENKINS-11716
Project: Jenkins
Issue Type: Bug
Components: core
Affects Versions: current
Reporter: Steve Roth

We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.
This generally works fine. However, I noticed that when I rename a job, I
lose the previous build records.
I see a new build record directory is created, beneath the specified 'Build
Record Root Directory'. However, the old build directory also exists,
containing the previous records. They are not moved over to the new
directory.
In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.
Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.

[JIRA] (JENKINS-11716) When 'Build Record Root Directory' is enabled, renaming a job does not create a new BRRD dir for the renamed job, and does not rename/copy artifacts from the original BRRD

2012-04-21 Thread sdrot...@gmail.com (JIRA)

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

Steve Roth updated JENKINS-11716:
-

Summary: When 'Build Record Root Directory' is enabled, renaming a job
does not create a new BRRD dir for the renamed job, and does not rename/copy
artifacts from the original BRRD (was: Renaming a job does not rename the
build record root dir, for a Jenkins instance configured with this feature)
Description:
We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.

The 'Build Record Root Directory' (set in configure system, then click
Advanced... button at the top), is set to
/scratch/jbuildroot/${ITEM_FULLNAME}/builds. The Workspace Root dir is set to
${ITEM_ROOTDIR}/workspace.

This generally works fine. However, I noticed that when I rename a job, I lose
the previous build records.

I see a new build record directory is created, beneath the specified 'Build
Record Root Directory'. However, the old build directory also exists,
containing the previous records. They are not moved over to the new directory.

In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.

Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.

was:
We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.

This generally works fine. However, I noticed that when I rename a job, I lose
the previous build records.

In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.

Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.

I noticed that in Jenkins v1.454, renaming a job does not even create the build
record root dir entry. For example, if I have build record root dir set to
/scratch/jbuildroot/${ITEM_FULLNAME}/builds and I rename a job 'foo' to 'bar',
then /scratch/jbuildroot/foo exists, but the rename does not create
/scratch/jbuildroot/bar.

I think in a previous version, this directory was at least created (though it
was empty), but in v1.454, I dont see it created anymore.

Updating the summary to reflect the new information.

When 'Build Record Root Directory' is enabled, renaming a job does not create
a new BRRD dir for the renamed job, and does not rename/copy artifacts from
the original BRRD
---

Key: JENKINS-11716
URL: https://issues.jenkins-ci.org/browse/JENKINS-11716
Project: Jenkins
Issue Type: Bug
Components: core
Affects Versions: current
Reporter: Steve Roth

We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.
The 'Build Record Root Directory' (set in configure system, then click
Advanced... button at the top), is set to
/scratch/jbuildroot/${ITEM_FULLNAME}/builds. The Workspace Root dir is set
to ${ITEM_ROOTDIR}/workspace.
This generally works fine. However, I noticed that when I rename a job, I
lose the previous build records.
I see a new build record directory is created, beneath the specified 'Build
Record Root Directory'. However, the old build directory also exists,
containing the previous records. They are not moved over to the new
directory.
In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.
Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.

[JIRA] (JENKINS-11716) When 'Build Record Root Directory' is enabled, renaming a job does not create a new BRRD dir for the renamed job, and does not rename/copy artifacts from the original BRRD

2012-04-21 Thread sdrot...@gmail.com (JIRA)


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

Steve Roth edited comment on JENKINS-11716 at 4/21/12 9:21 PM:
---

One shell script workaround for renaming the fileystem parts of job (presumes a 
path like ${ITEM_FULLNAME}/builds is listed below.   Save as 'renamejob.sh'.

First, backup your original job name directory, just in case.
Next, rename the job in the Jenkins UI.
Then run this script
Last, restart Jenkins (required).

Usage: renameJob.sh pathToBuildArtifactDir oldJobName newJobName

{code}
#!/bin/sh -eu

JOBROOT=$1
OLDJOB=$2
NEWJOB=$3

if [ ! -d $JOBROOT ]; then
echo ERROR: directory at JOBROOT=$JOBROOT does not exist
exit 1
fi

if [ ! -d $JOBROOT/$NEWJOB ]; then
  mkdir -p $JOBROOT/$NEWJOB
#echo ERROR: newjob directory at $JOBROOT/$NEWJOB does not exist
#exit 1
fi

if [ ! -d $JOBROOT/$OLDJOB ]; then
echo ERROR: oldjob directory at $JOBROOT/$OLDJOB does not exist
exit 1
fi

echo RENAMING JOB from $OLDJOB == $NEWJOB
set +e
rm -rf $JOBROOT/$NEWJOB/builds/*
mv $JOBROOT/$OLDJOB/* $JOBROOT/$NEWJOB
set -e

echo RENAMING OLD JOB TO END IN .old
set +e
mv $JOBROOT/$OLDJOB $JOBROOT/${OLDJOB}.old
set -e

echo UPDATING RUNS...
for RUNDIR in `ls -d $JOBROOT/$NEWJOB/builds/2012*`; do
echo ... UPDATING RUN AT $RUNDIR
if [ -f $JOBROOT/$RUNDIR/junitResult.xml ]; then
sed -i s/$OLDJOB/$NEWJOB/g $JOBROOT/$RUNDIR/junitResult.xml
fi
if [ -f $JOBROOT/$RUNDIR/build.xml ]; then
sed -i s/$OLDJOB/$NEWJOB/g $JOBROOT/$RUNDIR/build.xml
fi
done

echo REMOVING .old JOB (this may fail if more work is needed)
rmdir $JOBROOT/${OLDJOB}.old
{code}

  was (Author: sroth):
One shell script workaround for renaming the fileystem parts of job 
(presumes a path like ${ITEM_FULLNAME}/builds is listed below.   Save as 
'renamejob.sh'.

First, backup your original job name directory, just in case.
Next, rename the job in the Jenkins UI.
Then run this script
Last, restart Jenkins (required).

Usage: renameJob.sh oldJobName newJobName pathToBuildArtifactDir

#!/bin/sh -eu

OLDJOB=$1
NEWJOB=$2
JOBROOT=$3

if [ ! -d $JOBROOT ]; then
   echo ERROR: directory at JOBROOT=$JOBROOT does not exist
   exit 1
fi

if [ ! -d $JOBROOT/$NEWJOB ]; then
   echo ERROR: newjob directory at $JOBROOT/$NEWJOB does not exist
   exit 1
fi

if [ ! -d $JOBROOT/$OLDJOB ]; then
   echo ERROR: oldjob directory at $JOBROOT/$OLDJOB does not exist
   exit 1
fi

echo RENAMING JOB from $OLDJOB == $NEWJOB

set +e
rm -f $JOBROOT/last*
rm -rf $JOBROOT/$NEWJOB/builds/*
mv $JOBROOT/$OLDJOB/* $JOBROOT/$NEWJOB
set -e

echo UPDATING RUNS...
for RUNDIR in `ls -d $JOBROOT/$NEWJOB/builds/*-*-*`; do
  echo ... UPDATING RUN AT $RUNDIR
  if [ -f $JOBROOT/$RUNDIR/junitResult.xml ]; then
sed -i s/$OLDJOB/$NEWJOB/g $JOBROOT/$RUNDIR/junitResult.xml
  fi
  if [ -f $JOBROOT/$RUNDIR/build.xml ]; then
sed -i s/$OLDJOB/$NEWJOB/g $JOBROOT/$RUNDIR/build.xml
  fi
done

  
 When 'Build Record Root Directory' is enabled, renaming a job does not create 
 a new BRRD dir for the renamed job, and does not rename/copy artifacts from 
 the original BRRD
 ---

 Key: JENKINS-11716
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11716
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Steve Roth

 We have a Jenkins instance (1.438) using the 'Build Record Root Directory' 
 feature, so we can specify an alternate directory for storing build artifacts 
 outside of the JENKINS HOME directory.
 The 'Build Record Root Directory' (set in configure system, then click 
 Advanced... button at the top), is set to 
 /scratch/jbuildroot/${ITEM_FULLNAME}/builds.   The Workspace Root dir is set 
 to ${ITEM_ROOTDIR}/workspace.
 This generally works fine.  However, I noticed that when I rename a job, I 
 lose the previous build records.
 I see a new build record directory is created, beneath the specified 'Build 
 Record Root Directory'.  However, the old build directory also exists, 
 containing the previous records.  They are not moved over to the new 
 directory.
 In other words, when the 'Build Record Root Directory' feature is enabled, 
 renaming a project causes the project's build records to be lost.
 Current workaround is to move the build record files over and use sed to 
 replace the project name in them, then restart Jenkins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[JIRA] (JENKINS-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN


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

SCM/JIRA link daemon commented on JENKINS-12364:


Code changed in jenkins
User: Gregory Boissinot
Path:
 src/main/java/org/jenkinsci/CppcheckSourceContainer.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckPublisher.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java
http://jenkins-ci.org/commit/cppcheck-plugin/e5d5192f0fe518adc7e85e1c45fbcebbd735c6ab
Log:
  Fix JENKINS-12364






 Cannot drill down to source code with cppcheck when build source is checked 
 out using SVN
 -

 Key: JENKINS-12364
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12364
 Project: Jenkins
  Issue Type: Bug
  Components: cppcheck
Affects Versions: current
 Environment: Linux
Reporter: Chris Welch
Assignee: gbois
Priority: Minor

 Using the lastest cppcheck (v1.1).  cppcheck is unable to produce linkable 
 references to the source code when Subversion is used to check out the code.
 If you have a project that uses SVN, by default it is checked out into a sub 
 directory under the Jenkins workspace named as the last part of the 
 Subversion URL.  This is document in Jenkins in the If left empty portion 
 of the optional module local directory:
 Specify a local directory (relative to the workspace root) where this module 
 is checked out. If left empty, the last path component of the URL is used as 
 the default, just like the svn CLI. A single period (.) may be used to check 
 out the project directly into the workspace rather than into a subdirectory.
 So we have a project with a Subversion URL:
 svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj
 As a result, our Jenkins workspace becomes:
 /build/workspace/myproj_P2_0_0_cppcheck
 and the source code is checked out in:
 /build/workspace/myproj_P2_0_0_cppcheck/myproj
 cppcheck is run from the Jenkins workspace:
 /build/workspace/myproj_P2_0_0_cppcheck
 and the cppcheck-results.xml file ends up in the Jenkins workspace:
 /build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml
 But, the cppcheck reporter is not using the Jenkins workspace as the root for 
 references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck). 
  The cppcheck reporter is using the SVN check out location to generate the 
 report (/build/workspace/myproj_P2_0_0_cppcheck/myproj).  
 Here is an entry from the cppcheck-results.xml file:
 error file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c 
 id=s_tempStorageAssignment line=34 msg=Implicitly only sto
 rage pObj-gt;pOutVar (type ST_ADC_POINT_T *) not released before assignment: 
 pObj-gt;pOutVar = pOutObj A memory leak h
 as been detected. Only-qualified storage is not released before the last 
 reference to it is lost. (Use -mustfreeonly to
 inhibit warning) severity=warning/
 And the cppcheck plugin generates the following warning:
 [Cppcheck] [WARNING] - The source file 
 'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c'
  doesn't exist on the slave. The ability to display its source code has been 
 removed.  
 Note the duplication of the myproj directory.  The reporter is not using the 
 Jenkins workspace as the root directory.  It is using the SVN check out 
 directory.  The report generation should be built relative to the Jenkins 
 workspace, not to the SVN check out directory.
 This should be easy to fix.  The reporter should be using the present working 
 directory of the cppcheck-result.xml file as the path to prepend to the file 
 spec from the cppcheck-results.xml file.
 For example, in this case, the reporter start up to examin the 
 cppcheck-results.xml file:
 pwd
 /build/workspace/myproj_P2_0_0_cppcheck
 File in cppcheck-results.xml message:
 file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c
 File path is:
 pwd + cppcheck-results.xml file = 
 /build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI 
 Sharc/Shared/EDFA/deviceClass.c

--
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-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN


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

SCM/JIRA link daemon commented on JENKINS-12364:


Code changed in jenkins
User: Gregory Boissinot
Path:
 src/main/java/com/thalesgroup/hudson/plugins/cppcheck/CppcheckBuildAction.java
 src/main/java/org/jenkinsci/CppcheckSourceContainer.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckPublisher.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckSourceContainer.java
http://jenkins-ci.org/commit/cppcheck-plugin/ba87566276c491cde5d621894e90dcca8f9fdb51
Log:
  Fix JENKINS-12364






 Cannot drill down to source code with cppcheck when build source is checked 
 out using SVN
 -

 Key: JENKINS-12364
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12364
 Project: Jenkins
  Issue Type: Bug
  Components: cppcheck
Affects Versions: current
 Environment: Linux
Reporter: Chris Welch
Assignee: gbois
Priority: Minor

 Using the lastest cppcheck (v1.1).  cppcheck is unable to produce linkable 
 references to the source code when Subversion is used to check out the code.
 If you have a project that uses SVN, by default it is checked out into a sub 
 directory under the Jenkins workspace named as the last part of the 
 Subversion URL.  This is document in Jenkins in the If left empty portion 
 of the optional module local directory:
 Specify a local directory (relative to the workspace root) where this module 
 is checked out. If left empty, the last path component of the URL is used as 
 the default, just like the svn CLI. A single period (.) may be used to check 
 out the project directly into the workspace rather than into a subdirectory.
 So we have a project with a Subversion URL:
 svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj
 As a result, our Jenkins workspace becomes:
 /build/workspace/myproj_P2_0_0_cppcheck
 and the source code is checked out in:
 /build/workspace/myproj_P2_0_0_cppcheck/myproj
 cppcheck is run from the Jenkins workspace:
 /build/workspace/myproj_P2_0_0_cppcheck
 and the cppcheck-results.xml file ends up in the Jenkins workspace:
 /build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml
 But, the cppcheck reporter is not using the Jenkins workspace as the root for 
 references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck). 
  The cppcheck reporter is using the SVN check out location to generate the 
 report (/build/workspace/myproj_P2_0_0_cppcheck/myproj).  
 Here is an entry from the cppcheck-results.xml file:
 error file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c 
 id=s_tempStorageAssignment line=34 msg=Implicitly only sto
 rage pObj-gt;pOutVar (type ST_ADC_POINT_T *) not released before assignment: 
 pObj-gt;pOutVar = pOutObj A memory leak h
 as been detected. Only-qualified storage is not released before the last 
 reference to it is lost. (Use -mustfreeonly to
 inhibit warning) severity=warning/
 And the cppcheck plugin generates the following warning:
 [Cppcheck] [WARNING] - The source file 
 'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c'
  doesn't exist on the slave. The ability to display its source code has been 
 removed.  
 Note the duplication of the myproj directory.  The reporter is not using the 
 Jenkins workspace as the root directory.  It is using the SVN check out 
 directory.  The report generation should be built relative to the Jenkins 
 workspace, not to the SVN check out directory.
 This should be easy to fix.  The reporter should be using the present working 
 directory of the cppcheck-result.xml file as the path to prepend to the file 
 spec from the cppcheck-results.xml file.
 For example, in this case, the reporter start up to examin the 
 cppcheck-results.xml file:
 pwd
 /build/workspace/myproj_P2_0_0_cppcheck
 File in cppcheck-results.xml message:
 file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c
 File path is:
 pwd + cppcheck-results.xml file = 
 /build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI 
 Sharc/Shared/EDFA/deviceClass.c

--
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-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN

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

gbois resolved JENKINS-12364.
-

Resolution: Fixed

Cannot drill down to source code with cppcheck when build source is checked
out using SVN
-

Key: JENKINS-12364
URL: https://issues.jenkins-ci.org/browse/JENKINS-12364
Project: Jenkins
Issue Type: Bug
Components: cppcheck
Affects Versions: current
Environment: Linux
Reporter: Chris Welch
Assignee: gbois
Priority: Minor

Using the lastest cppcheck (v1.1). cppcheck is unable to produce linkable
references to the source code when Subversion is used to check out the code.
If you have a project that uses SVN, by default it is checked out into a sub
directory under the Jenkins workspace named as the last part of the
Subversion URL. This is document in Jenkins in the If left empty portion
of the optional module local directory:
Specify a local directory (relative to the workspace root) where this module
is checked out. If left empty, the last path component of the URL is used as
the default, just like the svn CLI. A single period (.) may be used to check
out the project directly into the workspace rather than into a subdirectory.
So we have a project with a Subversion URL:
svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj
As a result, our Jenkins workspace becomes:
/build/workspace/myproj_P2_0_0_cppcheck
and the source code is checked out in:
/build/workspace/myproj_P2_0_0_cppcheck/myproj
cppcheck is run from the Jenkins workspace:
/build/workspace/myproj_P2_0_0_cppcheck
and the cppcheck-results.xml file ends up in the Jenkins workspace:
/build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml
But, the cppcheck reporter is not using the Jenkins workspace as the root for
references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck).
The cppcheck reporter is using the SVN check out location to generate the
report (/build/workspace/myproj_P2_0_0_cppcheck/myproj).
Here is an entry from the cppcheck-results.xml file:
error file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c
id=s_tempStorageAssignment line=34 msg=Implicitly only sto
rage pObj-gt;pOutVar (type ST_ADC_POINT_T *) not released before assignment:
pObj-gt;pOutVar = pOutObj A memory leak h
as been detected. Only-qualified storage is not released before the last
reference to it is lost. (Use -mustfreeonly to
inhibit warning) severity=warning/
And the cppcheck plugin generates the following warning:
[Cppcheck] [WARNING] - The source file
'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c'
doesn't exist on the slave. The ability to display its source code has been
removed.
Note the duplication of the myproj directory. The reporter is not using the
Jenkins workspace as the root directory. It is using the SVN check out
directory. The report generation should be built relative to the Jenkins
workspace, not to the SVN check out directory.
This should be easy to fix. The reporter should be using the present working
directory of the cppcheck-result.xml file as the path to prepend to the file
spec from the cppcheck-results.xml file.
For example, in this case, the reporter start up to examin the
cppcheck-results.xml file:
pwd
/build/workspace/myproj_P2_0_0_cppcheck
File in cppcheck-results.xml message:
file=/myproj/ADI Sharc/Shared/EDFA/deviceClass.c
File path is:
pwd + cppcheck-results.xml file =
/build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI
Sharc/Shared/EDFA/deviceClass.c

[JIRA] (JENKINS-13466) Custom environment variables not available when build started by an SCM change