date:20120501


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

SCM/JIRA link daemon commented on JENKINS-13649:


Code changed in jenkins
User: Stephen Connolly
Path:
 core/src/main/java/hudson/FilePath.java
http://jenkins-ci.org/commit/jenkins/c92c2217ecb0078f021fab7c9a053d9e63f12143
Log:
  [FIXES JENKINS-13649] As FilePath(FilePath,String) expects multi-segment 
relative paths, we should ensure that the multiple segments are using the 
correct separator character for the remote OS




 Invalid environment variable values when running hierarchical jobs on windows 
 slaves
 

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

 If you try to run a hierarchical job on a windows slave the WORKSPACE 
 environment variable will contain slashes. 
 e.g.
 WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test
 The root cause of this is that Slave.getWorkspaceFor(...) calls 
 AbstractItem.getFullName() which will build up the name using '/' as the 
 separator.

--
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-13649) Invalid environment variable values when running hierarchical jobs on windows slaves


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

SCM/JIRA link daemon commented on JENKINS-13649:


Code changed in jenkins
User: Nicolas De loof
Path:
 core/src/main/java/hudson/FilePath.java
http://jenkins-ci.org/commit/jenkins/708b609ccce2ca8334acb9f5399a7d199a33880a
Log:
  Merge pull request #461 from stephenc/master

Fixes JENKINS-13649


Compare: https://github.com/jenkinsci/jenkins/compare/207134d...708b609



 Invalid environment variable values when running hierarchical jobs on windows 
 slaves
 

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

 If you try to run a hierarchical job on a windows slave the WORKSPACE 
 environment variable will contain slashes. 
 e.g.
 WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test
 The root cause of this is that Slave.getWorkspaceFor(...) calls 
 AbstractItem.getFullName() which will build up the name using '/' as the 
 separator.

--
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-13649) Invalid environment variable values when running hierarchical jobs on windows slaves


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

SCM/JIRA link daemon commented on JENKINS-13649:


Code changed in jenkins
User: Stephen Connolly
Path:
 core/src/test/java/hudson/FilePathTest.java
http://jenkins-ci.org/commit/jenkins/71debc2b8942844c721d7849b48286dc13c3c8db
Log:
  [JENKINS-13649] Adding a test case






 Invalid environment variable values when running hierarchical jobs on windows 
 slaves
 

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

 If you try to run a hierarchical job on a windows slave the WORKSPACE 
 environment variable will contain slashes. 
 e.g.
 WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test
 The root cause of this is that Slave.getWorkspaceFor(...) calls 
 AbstractItem.getFullName() which will build up the name using '/' as the 
 separator.

--
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-13649) Invalid environment variable values when running hierarchical jobs on windows slaves

2012-05-01 Thread stephenconno...@java.net (JIRA)


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

stephenconnolly resolved JENKINS-13649.
---

Resolution: Fixed

 Invalid environment variable values when running hierarchical jobs on windows 
 slaves
 

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

 If you try to run a hierarchical job on a windows slave the WORKSPACE 
 environment variable will contain slashes. 
 e.g.
 WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test
 The root cause of this is that Slave.getWorkspaceFor(...) calls 
 AbstractItem.getFullName() which will build up the name using '/' as the 
 separator.

--
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-12519) Test Statistic Grid will be rendered diffrently in IE9, Chrome, FF, Opera

2012-05-01 Thread marco.ambu+jenk...@gmail.com (JIRA)


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

Marco Ambu commented on JENKINS-12519:
--

Hi, can you please also provide some screenshot?

 Test Statistic Grid will be rendered diffrently in IE9, Chrome, FF, Opera 
 --

 Key: JENKINS-12519
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12519
 Project: Jenkins
  Issue Type: Bug
  Components: dashboard-view
 Environment: jenkins 1.445
 dashboard-view 2.1
 IE 9, FF 4-10, chrome, opera 
Reporter: Thomas Fürer
Assignee: Marco Ambu
Priority: Minor

 The job names are displayed in a centric style in IE9 and opera but are 
 displyed left bounded in FF and chrome.
 I would prefer left bounded.

--
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-13257) New Job - Copy existing Job fails with error Status Code: 500

2012-05-01 Thread marco.ambu+jenk...@gmail.com (JIRA)


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

Marco Ambu updated JENKINS-13257:
-

Component/s: (was: dashboard-view)

 New Job - Copy existing Job fails with error Status Code: 500
 

 Key: JENKINS-13257
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13257
 Project: Jenkins
  Issue Type: Bug
  Components: createjobadvanced
 Environment: from http://SERVER/systemInfo
 
 ALLUSERSPROFILE   C:\Dokumente und Einstellungen\All Users
 BASE  c:\Daten\Jenkins\.jenkins
 COMPUTERNAME  WST070736
 CSSCRIPT_DIR  C:\Programme\ETM\PVSS2\RAG\cs-script
 ComSpec   C:\WINDOWS\system32\cmd.exe
 CommonProgramFilesC:\Programme\Gemeinsame Dateien
 DISPLAY   wst070736:0.0
 DeviceTypeWST
 EXCURSIONSDK  C:\Programme\ETM\PVSS2\3.8
 FP_NO_HOST_CHECK  NO
 JENKINS_HOME  c:\Daten\Jenkins\.jenkins
 LC_NO_COMSERVER_REGISTRATION  1
 LDMS_LOCAL_DIRC:\Programme\LANDesk\LDClient\Data
 NIDAQmxSwitchDir  C:\Programme\National Instruments\NI-DAQ\Switch\
 NUMBER_OF_PROCESSORS  2
 OSWindows_NT
 PATHEXT   .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1
 PROCESSOR_ARCHITECTUREx86
 PROCESSOR_IDENTIFIER  x86 Family 6 Model 15 Stepping 2, GenuineIntel
 PROCESSOR_LEVEL   6
 PROCESSOR_REVISION0f02
 PSModulePath  C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
 PVSS_II   C:\Programme\ETM\PVSS2\3.8\config\config
 PVSS_II_HOME  C:\Programme\ETM\PVSS2\3.8
 Path  
 C:\Programme\ETM\PVSS2\3.8\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Programme\IVI
  Foundation\VISA\WinNT\Bin\;C:\Programme\IVI 
 Foundation\VISA\WinNT\Bin;C:\Daten\Python26;C:\Programme\Mozilla 
 Firefox;c:\Programme\Microsoft SQL 
 Server\90\Tools\binn\;C:\Programme\gKP\Bin\;C:\Programme\TortoiseSVN\bin
 ProgramFiles  C:\Programme
 SystemDrive   C:
 SystemRootC:\WINDOWS
 TEMP  C:\WINDOWS\TEMP
 TMP   C:\WINDOWS\TEMP
 USERPROFILE   C:\Dokumente und Einstellungen\LocalService
 VISUALSVN_SERVER  C:\Programme\VisualSVN Server\
 VXIPNPPATHC:\Programme\IVI Foundation\VISA\
 gKPDirC:\Programme\gKP\
 windirC:\WINDOWS
 
Reporter: Stephan Schwerzmann
  Labels: jenkins, job, windows

 New Job - Copy existing Job fails with error Status Code: 500
 The job used as source for the copy runs well (our nightly build - hey: it 
 even succeeds :-)
 The new job is created, but no data is in any of the configuration fields.
 The new job (empty) can be deleted.
 Following stacktrace is shown in the Webbrowser:
 
 Status Code: 500
 Exception:
 Stacktrace:
 Warning: Could not find file 
 c:\Daten\Jenkins\.jenkins\jobs\RIMOCTRL_SW_VxWorks-6.7_dev\config.xml to copy.
   at org.apache.tools.ant.taskdefs.Copy.copySingleFile(Copy.java:573)
   at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:403)
   at hudson.Util.copyFile(Util.java:840)
   at hudson.model.ItemGroupMixIn.copy(ItemGroupMixIn.java:203)
   at 
 hudson.model.ItemGroupMixIn.createTopLevelItem(ItemGroupMixIn.java:164)
   at jenkins.model.Jenkins.doCreateItem(Jenkins.java:2733)
   at jenkins.model.Jenkins.doCreateItem(Jenkins.java:300)
   at hudson.model.AllView.doCreateItem(AllView.java:76)
   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 
 org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
   at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
   at 
 org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
   at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
   at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
   at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
   at

[JIRA] (JENKINS-7887) Inconsistency regarding plugin names inside pluginManger pages

2012-05-01 Thread marco.ambu+jenk...@gmail.com (JIRA)


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

Marco Ambu reassigned JENKINS-7887:
---

Assignee: Marco Ambu

 Inconsistency regarding plugin names inside pluginManger pages
 --

 Key: JENKINS-7887
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7887
 Project: Jenkins
  Issue Type: Bug
  Components: plugin
Reporter: ssbarnea
Assignee: Marco Ambu
Priority: Minor

 All the URLs from the /pluginManager/installed should have exact the same 
 names as the plugin - as it is listed inside /pluginManager/available
 This is really important because I found out that is hard to identify a 
 plugin using the find-in-page search in browser.
 Just one example (there are tens of them):
 XShell Plugin is listed as Hudson cross-platform shell plugin, searching 
 by xshell will find nothing.
 I'm not sure if this could be easily changed but an alternative solution 
 would be just to include the plugin name before the description inside the 
 /installed page.
 Anyway, the idea is the all the naming must be consistent in order to prevent 
 confusion.

--
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-13586) Latest builds portlet show all Jobentries with the current state icon,but it should be the build result state Icon.

2012-05-01 Thread marco.ambu+jenk...@gmail.com (JIRA)


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

Marco Ambu reassigned JENKINS-13586:


Assignee: Marco Ambu  (was: Peter Hayes)

 Latest builds portlet show all Jobentries with the current state icon,but 
 it should be the build result state Icon.
 -

 Key: JENKINS-13586
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13586
 Project: Jenkins
  Issue Type: Improvement
  Components: dashboard-view
Affects Versions: current
 Environment: Jenkins 1.460; Debian Lenny
Reporter: Wolfgang Hauser
Assignee: Marco Ambu
Priority: Minor
 Fix For: current


 If a Job changes its state, all entries of this job in Latest builds 
 portlet are prefixed with the same Icon (e.g flashing for currently 
 working).
 It may be better to take the state of the build number as value for 
 displaying the state of the Job entry. (as it is done in the Build column.)

--
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-13424) Need option to run accurev replica sync before populating the stream

2012-05-01 Thread pjdar...@java.net (JIRA)


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

pjdarton commented on JENKINS-13424:


I had a flurry of activity on it until I got it working for me.  There's 
still some stuff unresolved from my point of view, but it's good enough and 
real work (what I was doing which meant I found the problems in the first 
place) then intervened and I stopped.

I think that your configuration setting should really be on a per-server basis, 
not global and not per-project, as it's necessary when you're building from a 
replica server instead of the master.

I think that your approach of emailing people is probably the right one - I 
don't have commit access to the repo either, but I did as you did - made a 
patch and asked for it to be included.  It might make life a little simpler if 
you get your own github fork, put the changes on there and then ask for that to 
be pulled, but a .patch file ought to work just as well.
If you don't get any response, you can always build a local copy and use that.

 Need option to run accurev replica sync before populating the stream
 --

 Key: JENKINS-13424
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13424
 Project: Jenkins
  Issue Type: Bug
  Components: accurev
 Environment: plugin version is 0.6.18
Reporter: pickgr1
Assignee: Scott Tatum
 Attachments: JENKINS-13424.patch


 This needs to either be an option or the default behavior.  Ideally, this is 
 the default behavior or a global setting so we don't have to re-configure all 
 of our projects.

--
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-12913) Unnecessary logging in hudson.plugins.accurev.ParseChangeLog

2012-05-01 Thread pjdar...@java.net (JIRA)


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

pjdarton commented on JENKINS-12913:


Yes, it was left in.  This code has a lot of history behind it.

Might be an idea to turn the log level down a notch (e.g. to debug) instead of 
completely removing it though - when things go wrong, such logging is very 
useful.

 Unnecessary logging in hudson.plugins.accurev.ParseChangeLog
 

 Key: JENKINS-12913
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12913
 Project: Jenkins
  Issue Type: Bug
  Components: accurev
Affects Versions: current
Reporter: pickgr1
Assignee: Scott Tatum

 Our jenkins logs fill up with the following:
 Feb 27, 2012 7:13:22 PM hudson.plugins.accurev.ParseChangeLog parse
 INFO: transactions size = 1
 It's not particularly useful - perhaps it was left on inadvertantly.

--
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-13649) Invalid environment variable values when running hierarchical jobs on windows slaves


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

dogfood commented on JENKINS-13649:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! 
[jenkins_main_trunk #1697|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1697/]
 [FIXES JENKINS-13649] As FilePath(FilePath,String) expects multi-segment 
relative paths, we should ensure that the multiple segments are using the 
correct separator character for the remote OS (Revision 
c92c2217ecb0078f021fab7c9a053d9e63f12143)
[JENKINS-13649] Adding a test case (Revision 
71debc2b8942844c721d7849b48286dc13c3c8db)

 Result = UNSTABLE
Stephen Connolly : 
[c92c2217ecb0078f021fab7c9a053d9e63f12143|https://github.com/jenkinsci/jenkins/commit/c92c2217ecb0078f021fab7c9a053d9e63f12143]
Files : 
* core/src/main/java/hudson/FilePath.java

Stephen Connolly : 
[71debc2b8942844c721d7849b48286dc13c3c8db|https://github.com/jenkinsci/jenkins/commit/71debc2b8942844c721d7849b48286dc13c3c8db]
Files : 
* core/src/test/java/hudson/FilePathTest.java


 Invalid environment variable values when running hierarchical jobs on windows 
 slaves
 

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

 If you try to run a hierarchical job on a windows slave the WORKSPACE 
 environment variable will contain slashes. 
 e.g.
 WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test
 The root cause of this is that Slave.getWorkspaceFor(...) calls 
 AbstractItem.getFullName() which will build up the name using '/' as the 
 separator.

--
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-13650) Upgrading Active Directory plugin from 1.26 to 1.27 reported as failure then causes loss of Jenkins admin rights

2012-05-01 Thread ml+j...@tomfanning.eu (JIRA)

Tom Fanning created JENKINS-13650:
-

 Summary: Upgrading Active Directory plugin from 1.26 to 1.27 
reported as failure then causes loss of Jenkins admin rights
 Key: JENKINS-13650
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13650
 Project: Jenkins
  Issue Type: Bug
  Components: active-directory
 Environment: Windows Server 2003 x86, non-domain, connecting to 
Windows Server 2008 Active Directory. Domain Name set to ourcompanyname.com, 
Domain controller left blank. Jenkins version=1.450, AD plugin version=1.26
Reporter: Tom Fanning


I just updated the AD plugin with install without restarting turned on to 
attempt to fix bug 12619 which I originally reported.

It failed:

INFO: Starting the installation of Active Directory plugin on behalf of tfanning
01-May-2012 11:23:40 hudson.model.UpdateCenter$UpdateCenterConfiguration 
download
INFO: Downloading Active Directory plugin
01-May-2012 11:23:41 hudson.PluginManager dynamicLoad
INFO: Attempting to dynamic load C:\Program 
Files\Jenkins\plugins\active-directory.jpi
01-May-2012 11:23:41 hudson.model.UpdateCenter$DownloadJob run
SEVERE: Failed to install Active Directory plugin
hudson.util.IOException2: Failed to dynamically deploy this plugin
at 
hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1137)
at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:955)
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.io.IOException: Unable to delete C:\Program 
Files\Jenkins\plugins\active-directory\WEB-INF\lib\active-directory-1.0.jar
at hudson.Util.deleteFile(Util.java:237)
at hudson.Util.deleteRecursive(Util.java:287)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.Util.deleteRecursive(Util.java:278)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.Util.deleteRecursive(Util.java:278)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.ClassicPluginStrategy.explode(ClassicPluginStrategy.java:389)
at 
hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.java:113)
at hudson.PluginManager.dynamicLoad(PluginManager.java:340)
at 
hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1133)
... 7 more

I then restarted the Jenkins service, waited, logged in with my AD credentials, 
so this appeared to work.

However in Jenkins my AD account has now lost all of its admin privileges, i.e. 
I nor any other person configured to have admin rights can now configure 
Jenkins.

I noticed active-directory.bak left over in the Jenkins plugin folder. Stopped 
the service, deleted active-directory.jpi, renamed active-directory.bak to 
.jpi, restarted, all working (albeit with bug 12619 still present)

How should I upgrade to 1.27 safely?

--
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-13427) Configuration view displays ERROR/Not Found under the edit boxes

2012-05-01 Thread daca...@gmail.com (JIRA)


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

Dave Carey commented on JENKINS-13427:
--

Just to add that I'm seeing the same issues as the guys above

All of the ERROR linnks display the following under tomcat

HTTP Status 404 - /plugin/thinBackup/checkBackupPath

 Configuration view displays ERROR/Not Found under the edit boxes
 

 Key: JENKINS-13427
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13427
 Project: Jenkins
  Issue Type: Bug
  Components: thinBackup
Reporter: Alexander Shusherov
Assignee: Thomas Fürer
Priority: Minor
 Attachments: thinBackup-config.jpg


 Hello, thinBackup developers! Thanks for a great plugin - we've been using it 
 for several months and it's very helpful!
 2 cents though.
 We've recently started to observe the attached picture. I.e. messages 
 ERROR, Not Found. Sorry!The page requested was not found. under the edit 
 boxes.
 We are behind the proxy. The global jenkins proxy config (as well as the 
 config for the container) is correct - jenkins receives updates for plugins 
 successfully.

--
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-13500) Jira plugin post integrated in comment on every build

2012-05-01 Thread ric...@java.net (JIRA)

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

ricktw commented on JENKINS-13500:
--

Well,

I've found the cause of this strange behavior:
The plugin was trying to comment on an issue which does not have 'comments'
activated. In this case the plugin also logs:
{code}
Error updating JIRA issues. Saving issues for next build.
com.atlassian.jira.rpc.exception.RemoteException: Errors: {}
Error Messages: [Jenkins, you do not have the permission to comment on this
issue.]
{code}
which is a bit misleading because of the '... permission ...' part.

When this happens *all* detected Jira issues are stored to be registered in the
next build (JiraCarryOverAction), even the ones which already have been
processed.
This is why the Integrated in message is posted over-and-over-again.

I think only the issues which are not processed correctly should be stored in
'JiraCarryOverAction'.

ps. I think this issue also occurs when this plugin is trying to comment on
issues were commenting is activated but were the configured user does not have
access to.

Jira plugin post integrated in comment on every build
---

Key: JENKINS-13500
URL: https://issues.jenkins-ci.org/browse/JENKINS-13500
Project: Jenkins
Issue Type: Bug
Components: jira
Reporter: ricktw

An Integrated in build XYZ comment is added for every build of a job when
no svn changes of the specific issue was detected.

--
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-12819) PTC Integrity Plugin does not checkout project again, if workspace has been deleted


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

SCM/JIRA link daemon commented on JENKINS-12819:


Code changed in jenkins
User: Your Name
Path:
 .classpath
 pom.xml
 src/main/java/hudson/scm/APISession.java
 src/main/java/hudson/scm/CM_PROJECT.java
 src/main/java/hudson/scm/DerbyUtils.java
 src/main/java/hudson/scm/IntegrityCMMember.java
 src/main/java/hudson/scm/IntegrityCMProject.java
 src/main/java/hudson/scm/IntegrityCheckoutTask.java
 src/main/java/hudson/scm/IntegrityItemAction.java
 src/main/java/hudson/scm/IntegrityRevisionState.java
 src/main/java/hudson/scm/IntegritySCM.java
 src/main/java/hudson/scm/Logger.java
 src/main/resources/hudson/scm/IntegritySCM/config.jelly
 src/main/resources/hudson/scm/IntegritySCM/help-fetchChangedWorkspaceFiles.html
http://jenkins-ci.org/commit/integrity-plugin/fea9c4043ab86536188b7f8790f227eddea68010
Log:
  Performed a major change in the SCM Project caching architecture on the 
Jenkins server
Additionally, the following issues have been addressed:
JENKINS-13221
JENKINS-12819




 PTC Integrity Plugin does not checkout project again, if workspace has been 
 deleted
 ---

 Key: JENKINS-12819
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12819
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Jenkins 1.451, PTC Integrity Plugin 1.12
Reporter: Holger Mense
Assignee: Cletus D'Souza

 If a file is deleted inside the project workspace, it will not be checked out 
 again by the Integrity-Plugin. However this can be done with Jenkins by using 
 Wipe Out Workspace.
 As far as I have digged into the code, the layout of the last checkout is 
 persisted in a file.  This information is then used to compare with the 
 current MKS data in order to decide which files to update. 
 I thought deleting viewproject.dat would be a workaround for this problem, 
 but it didn't help :(

--
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-13221) The integration does not examine the filesystem to see if files in the workspace is missing.


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

SCM/JIRA link daemon commented on JENKINS-13221:


Code changed in jenkins
User: Your Name
Path:
 .classpath
 pom.xml
 src/main/java/hudson/scm/APISession.java
 src/main/java/hudson/scm/CM_PROJECT.java
 src/main/java/hudson/scm/DerbyUtils.java
 src/main/java/hudson/scm/IntegrityCMMember.java
 src/main/java/hudson/scm/IntegrityCMProject.java
 src/main/java/hudson/scm/IntegrityCheckoutTask.java
 src/main/java/hudson/scm/IntegrityItemAction.java
 src/main/java/hudson/scm/IntegrityRevisionState.java
 src/main/java/hudson/scm/IntegritySCM.java
 src/main/java/hudson/scm/Logger.java
 src/main/resources/hudson/scm/IntegritySCM/config.jelly
 src/main/resources/hudson/scm/IntegritySCM/help-fetchChangedWorkspaceFiles.html
http://jenkins-ci.org/commit/integrity-plugin/fea9c4043ab86536188b7f8790f227eddea68010
Log:
  Performed a major change in the SCM Project caching architecture on the 
Jenkins server
Additionally, the following issues have been addressed:
JENKINS-13221
JENKINS-12819




 The integration does not examine the filesystem to see if files in the 
 workspace is missing.
 

 Key: JENKINS-13221
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13221
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Linux/x64
Reporter: Eric Youngdale
Assignee: Cletus D'Souza

 Due to the extreme amount of time required to repopulate a workspace, we run 
 our Hudson build without doing a clean of the workspace with each build.  
 Thus in the normal case, we have a build run once an hour, it downloads all 
 changed files, and then it does the build.
 But if a file in the workspace is missing or corrupt, it doesn't attempt to 
 re-download the file.  Determining if the file is corrupt might be tricky (I 
 suppose one might store an MD5 sum in the local database for the workspace).  
 But when you have a file that is missing from the workspace, it ought to be a 
 no-brainer that the SCM plugin should download a new copy of the file.
 I ran across this because I used this bug/feature as a workaround for this 
 issue:
 https://issues.jenkins-ci.org/browse/JENKINS-13220

--
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-8075) Assign role interface does not scale to large number of users and roles

2012-05-01 Thread jamie.ingi...@betfair.com (JIRA)

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

Jamie I commented on JENKINS-8075:
--

@Romain: Was your update ever released?

Assign role interface does not scale to large number of users and roles
---

Key: JENKINS-8075
URL: https://issues.jenkins-ci.org/browse/JENKINS-8075
Project: Jenkins
Issue Type: Improvement
Components: role-strategy
Environment: Hudson 1.381, Role based strategy 1.0
Reporter: Costin Caraivan
Assignee: Daniel Petisme
Priority: Minor
Attachments: JENKINS-8075.png, roleassignment-mockup.png,
roleassignment-original.png

Hello,
Our Hudson deployment has a lot of independent projects which need to have
several roles assigned inside the team, some team members having more rights
than others. The end result: lots of users, lots of projects x several roles
per project = a huge bunch of roles.
The number of users and roles will only increase - right now we are at about
50% of the final capacity.
Trying to use the Role Based Strategy plugin, we noticed some scaling issues
with the Assign roles page. See roleassignment-original.png attachment for
the problems.
Notice the scroll bars when having lots of users and roles. Having lots of
users is ok, vertical scrolling is something common on webpages. However,
having both vertical scrolling and horizontal scrolling is confusing. The
Hudson row/column highlight is helpful, however the interface is still
cumbersome.
I would propose the following interface change for the assign roles page:
- add a text box to each table row; preferably with role autocompletion, if
possible
- add a label with the list or roles for each user
See the roleassignement-mockup.png attachment.
Thank you for your help.
I propose a different design for the page, to allow it to scale when having
lots of users and roles

[JIRA] (JENKINS-13646) Automatically Created Clients missing Owner: in clientspec

2012-05-01 Thread rob.pe...@gmail.com (JIRA)

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

Rob Petti commented on JENKINS-13646:
-

I've just added an option for the owner field to the build here:
http://ci.jenkins-ci.org/job/plugins_perforce/222/artifact/target/perforce.hpi

I haven't had a chance to test it yet, though.

Automatically Created Clients missing Owner: in clientspec
--

Key: JENKINS-13646
URL: https://issues.jenkins-ci.org/browse/JENKINS-13646
Project: Jenkins
Issue Type: New Feature
Components: perforce
Affects Versions: current
Environment: Linux
Reporter: David Baird
Assignee: Rob Petti

My Perforce environment has a requirement that Owner: is defined in the
clientspec when creating or modifying a cleint. I don't really understand how
this requirement is enforced, just that now, 'p4 client' throws an error if
the Owner field is missing from the clientspec. I see a problem with the
Perforce plugin is managing the cleint:
/usr/bin/p4 -s client -i
Caught exception communicating with perforce. Error in client specification.
Missing required field 'Owner'.
For Command: /usr/bin/p4 -s client -i
With Data:
===
Client:
Description:
Root: /var/lib/jenkins/jobs//workspace
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
LineEnd: local
View:
//depot//... ///...

[JIRA] (JENKINS-13632) AbstractMethodError with PTC Integrity Plugin


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

Cletus D'Souza commented on JENKINS-13632:
--

I've not been able to reproduce this problem.  Seems to be some sort of apache 
commons httpclient incompatibility between what is packaged with Jenkins and 
the mksapi.jar

 AbstractMethodError with PTC Integrity Plugin
 -

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

 I get the following error after I upgraded Jenkins as well as the plugin:
 16:51:33  FATAL: 
 com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
 16:51:33  java.lang.AbstractMethodError: 
 com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
 16:51:33  at 
 org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
 16:51:33  at 
 org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
 16:51:33  at 
 org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
 16:51:33  at 
 org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
 16:51:33  at 
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
 16:51:33  at 
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.handleHTTPResponse(UserApplicationSessionImpl.java:304)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.getSession(UserApplicationSessionImpl.java:350)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.getSessionURI(UserApplicationSessionImpl.java:413)
 16:51:33  at 
 com.mks.connect.HttpCmdRunnerImpl.getSessionURI(HttpCmdRunnerImpl.java:72)
 16:51:33  at 
 com.mks.connect.HttpBlimpInputStream.getSessionURI(HttpBlimpInputStream.java:125)
 16:51:33  at 
 com.mks.connect.HttpBlimpInputStream.blimpInitiate(HttpBlimpInputStream.java:152)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.getInputStream(BlimpInputStream.java:223)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.readNoEof(BlimpInputStream.java:693)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.handleNextBlimpCommand(BlimpInputStream.java:266)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.read(BlimpInputStream.java:190)
 When I downgrade to Jenkins 1.419 everything works fine again!

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

[JIRA] (JENKINS-13220) The integration inconsistently handles change packages that are submitted but not yet accepted.

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

Cletus D'Souza resolved JENKINS-13220.
--

Resolution: Not A Defect

Seems like a Integrity product issue, not a plug-in issue

The integration inconsistently handles change packages that are submitted but
not yet accepted.
---

Key: JENKINS-13220
URL: https://issues.jenkins-ci.org/browse/JENKINS-13220
Project: Jenkins
Issue Type: Bug
Components: integrity-plugin
Affects Versions: current
Environment: Linux/x64.
Reporter: Eric Youngdale
Assignee: Cletus D'Souza
Labels: plugins

We had an issue whereby there were a set of changes which were submitted but
not yet accepted into MKS Source. Some of the changes involved new source
files (JUnit tests in this case), and others involved changes to existing
files.
What I am seeing is that regarding changes to existing files, the plugin
correctly does not download them until the change package is eventually
accepted. However for any new files, this isn't the case - it downloads the
immediately no matter what the status of the change package.
In our case the new JUnit tests were being automatically run even though the
corresponding changes had not yet been applied and it caused the build to
fail.

[JIRA] (JENKINS-13221) The integration does not examine the filesystem to see if files in the workspace is missing.


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

Cletus D'Souza resolved JENKINS-13221.
--

Resolution: Fixed

Fixed with release 1.13

 The integration does not examine the filesystem to see if files in the 
 workspace is missing.
 

 Key: JENKINS-13221
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13221
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Linux/x64
Reporter: Eric Youngdale
Assignee: Cletus D'Souza

 Due to the extreme amount of time required to repopulate a workspace, we run 
 our Hudson build without doing a clean of the workspace with each build.  
 Thus in the normal case, we have a build run once an hour, it downloads all 
 changed files, and then it does the build.
 But if a file in the workspace is missing or corrupt, it doesn't attempt to 
 re-download the file.  Determining if the file is corrupt might be tricky (I 
 suppose one might store an MD5 sum in the local database for the workspace).  
 But when you have a file that is missing from the workspace, it ought to be a 
 no-brainer that the SCM plugin should download a new copy of the file.
 I ran across this because I used this bug/feature as a workaround for this 
 issue:
 https://issues.jenkins-ci.org/browse/JENKINS-13220

--
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-12819) PTC Integrity Plugin does not checkout project again, if workspace has been deleted


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

Cletus D'Souza resolved JENKINS-12819.
--

Resolution: Fixed

Fixed with version 1.13

 PTC Integrity Plugin does not checkout project again, if workspace has been 
 deleted
 ---

 Key: JENKINS-12819
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12819
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Jenkins 1.451, PTC Integrity Plugin 1.12
Reporter: Holger Mense
Assignee: Cletus D'Souza

 If a file is deleted inside the project workspace, it will not be checked out 
 again by the Integrity-Plugin. However this can be done with Jenkins by using 
 Wipe Out Workspace.
 As far as I have digged into the code, the layout of the last checkout is 
 persisted in a file.  This information is then used to compare with the 
 current MKS data in order to decide which files to update. 
 I thought deleting viewproject.dat would be a workaround for this problem, 
 but it didn't help :(

--
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-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks


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

SCM/JIRA link daemon commented on JENKINS-13647:


Code changed in jenkins
User: Gregory Boissinot
Path:
 pom.xml
 src/main/java/hudson/plugins/batch_task/BatchRun.java
http://jenkins-ci.org/commit/batch-task-plugin/69b3bde996d5500b18c69f582c7c14e5d1ef9fe4
Log:
  Fix JENKINS-13647






 Environment variables from EnvInject plugin are not inherited/parsed by batch 
 tasks
 ---

 Key: JENKINS-13647
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13647
 Project: Jenkins
  Issue Type: Bug
  Components: batch-task
Affects Versions: current
Reporter: tsondergaard
Assignee: Kohsuke Kawaguchi
 Attachments: config.xml


 Environment variables set for a job with the Prepare an environment for the 
 run and not processed/used for batch tasks. This is very similar to bug 
 JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin

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

[JIRA] (JENKINS-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks


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

gbois resolved JENKINS-13647.
-

Resolution: Fixed

 Environment variables from EnvInject plugin are not inherited/parsed by batch 
 tasks
 ---

 Key: JENKINS-13647
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13647
 Project: Jenkins
  Issue Type: Bug
  Components: batch-task
Affects Versions: current
Reporter: tsondergaard
Assignee: Kohsuke Kawaguchi
 Attachments: config.xml


 Environment variables set for a job with the Prepare an environment for the 
 run and not processed/used for batch tasks. This is very similar to bug 
 JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin

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

[JIRA] (JENKINS-12163) Cleaning VM before start next job in queue.

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

SCM/JIRA link daemon commented on JENKINS-12163:

Code changed in jenkins
User: Jason Swager
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/vSphereCloudLauncher.java
src/main/java/org/jenkinsci/plugins/vSphereCloudRunListener.java
src/main/java/org/jenkinsci/plugins/vSphereCloudSlave.java

src/main/resources/org/jenkinsci/plugins/vSphereCloudSlave/configure-entries.jelly
src/main/webapp/slave-LimitedTestRunCount.html
http://jenkins-ci.org/commit/vsphere-cloud-plugin/cc473a3d10142042bf1d53e139c3302b0be494be
Log:
Changes to address JENKINS-12163: Clean the VM after X many builds.

Cleaning VM before start next job in queue.
---

Key: JENKINS-12163
URL: https://issues.jenkins-ci.org/browse/JENKINS-12163
Project: Jenkins
Issue Type: Bug
Components: vsphere-cloud
Reporter: Alexey Larsky

Sylvain Chagnaud says: Hi, it's a very useful plugin. But I have a little
comment for a specific case. ...
Hi, it's a very useful plugin. But I have a little comment for a specific
case. In fact I want to revert to a snapshot before each job execution but if
several jobs try to run on the VMWare at the same time then the VMWare can't
revert to the snapshot. Do you have a solution, thank you ?
jswager - says: At the moment, I don't have a solution incorporated into the
plugin. But I...
At the moment, I don't have a solution incorporated into the plugin. But I'm
working on it. In the meantime, here's a workaround:
1) Configure the slave with a disconnect type of Revert or Reset.
2) In your test job, mark the slave temporarily offline. This will prevent
further jobs from targeting the slave. It would be something like this:
curl -d
offlineMessage=back_in_a_momentjson=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7DSubmit=Mark+this+node+temporarily+offline
http://JENKINS_HOST/computer/NODE_TO_DISCONNECT/toggleOffline
3) As a final step in your job, start a delayed shutdown of the VM. If it's
Windows, something like shutdown /s /t

[JIRA] (JENKINS-12163) Cleaning VM before start next job in queue.

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

Jason Swager commented on JENKINS-12163:

Fixed via
https://github.com/jenkinsci/vsphere-cloud-plugin/commit/cc473a3d10142042bf1d53e139c3302b0be494be
Targeted for 0.6

Cleaning VM before start next job in queue.
---

Key: JENKINS-12163
URL: https://issues.jenkins-ci.org/browse/JENKINS-12163
Project: Jenkins
Issue Type: Bug
Components: vsphere-cloud
Reporter: Alexey Larsky

[JIRA] (JENKINS-12163) Cleaning VM before start next job in queue.

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

Jason Swager reassigned JENKINS-12163:
--

Assignee: Jason Swager

Cleaning VM before start next job in queue.
---

Key: JENKINS-12163
URL: https://issues.jenkins-ci.org/browse/JENKINS-12163
Project: Jenkins
Issue Type: Bug
Components: vsphere-cloud
Reporter: Alexey Larsky
Assignee: Jason Swager

[JIRA] (JENKINS-12163) Cleaning VM before start next job in queue.

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

Work on JENKINS-12163 started by Jason Swager.

Cleaning VM before start next job in queue.
---

Key: JENKINS-12163
URL: https://issues.jenkins-ci.org/browse/JENKINS-12163
Project: Jenkins
Issue Type: Bug
Components: vsphere-cloud
Reporter: Alexey Larsky
Assignee: Jason Swager

[JIRA] (JENKINS-12241) Test Connection fails if vSphere host contains trailing slash ('/') character


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

Jason Swager reassigned JENKINS-12241:
--

Assignee: Jason Swager

 Test Connection fails if vSphere host contains trailing slash ('/') character
 -

 Key: JENKINS-12241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12241
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
 Environment: Windows 7 x64
Reporter: Garen Parham
Assignee: Jason Swager

 Subject says it all, really.  Use a trailing '/' when specifying a new 
 vSphere host, click the 'Test Connection' button and the text ERROR is 
 displayed.

--
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-12241) Test Connection fails if vSphere host contains trailing slash ('/') character


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

Work on JENKINS-12241 started by Jason Swager.

 Test Connection fails if vSphere host contains trailing slash ('/') character
 -

 Key: JENKINS-12241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12241
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
 Environment: Windows 7 x64
Reporter: Garen Parham
Assignee: Jason Swager

 Subject says it all, really.  Use a trailing '/' when specifying a new 
 vSphere host, click the 'Test Connection' button and the text ERROR is 
 displayed.

--
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-12241) Test Connection fails if vSphere host contains trailing slash ('/') character


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

SCM/JIRA link daemon commented on JENKINS-12241:


Code changed in jenkins
User: Jason Swager
Path:
 src/main/java/org/jenkinsci/plugins/vSphereCloud.java
 src/main/webapp/vsHost.html
http://jenkins-ci.org/commit/vsphere-cloud-plugin/80cee2dd2d1926454678b2bf0290207d8504db4a
Log:
  JENKINS-12241: Test Connection fails if vSphere host contains trailing slash 
('/') character






 Test Connection fails if vSphere host contains trailing slash ('/') character
 -

 Key: JENKINS-12241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12241
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
 Environment: Windows 7 x64
Reporter: Garen Parham
Assignee: Jason Swager

 Subject says it all, really.  Use a trailing '/' when specifying a new 
 vSphere host, click the 'Test Connection' button and the text ERROR is 
 displayed.

--
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-12241) Test Connection fails if vSphere host contains trailing slash ('/') character


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

Jason Swager commented on JENKINS-12241:


Fixed with 
https://github.com/jenkinsci/vsphere-cloud-plugin/commit/80cee2dd2d1926454678b2bf0290207d8504db4a
Targeted version 0.6

 Test Connection fails if vSphere host contains trailing slash ('/') character
 -

 Key: JENKINS-12241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12241
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
 Environment: Windows 7 x64
Reporter: Garen Parham
Assignee: Jason Swager

 Subject says it all, really.  Use a trailing '/' when specifying a new 
 vSphere host, click the 'Test Connection' button and the text ERROR is 
 displayed.

--
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-13537) Not perform revert snapshot for all vmwares of a label


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

Jason Swager reassigned JENKINS-13537:
--

Assignee: Jason Swager

 Not perform revert snapshot for all vmwares of a label
 

 Key: JENKINS-13537
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13537
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
Reporter: Sylvain C.
Assignee: Jason Swager

 When a job restricted to only one label is launched, the plugin performs a 
 revert snapshot of all the vmwares that have this label

--
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-13537) Not perform revert snapshot for all vmwares of a label


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

Work on JENKINS-13537 started by Jason Swager.

 Not perform revert snapshot for all vmwares of a label
 

 Key: JENKINS-13537
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13537
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
Reporter: Sylvain C.
Assignee: Jason Swager

 When a job restricted to only one label is launched, the plugin performs a 
 revert snapshot of all the vmwares that have this label

--
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-12241) Test Connection fails if vSphere host contains trailing slash ('/') character


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

Jason Swager resolved JENKINS-12241.


Resolution: Fixed

 Test Connection fails if vSphere host contains trailing slash ('/') character
 -

 Key: JENKINS-12241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12241
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Affects Versions: current
 Environment: Windows 7 x64
Reporter: Garen Parham
Assignee: Jason Swager

 Subject says it all, really.  Use a trailing '/' when specifying a new 
 vSphere host, click the 'Test Connection' button and the text ERROR is 
 displayed.

--
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-12163) Cleaning VM before start next job in queue.

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

Jason Swager resolved JENKINS-12163.

Resolution: Fixed

Cleaning VM before start next job in queue.
---

Key: JENKINS-12163
URL: https://issues.jenkins-ci.org/browse/JENKINS-12163
Project: Jenkins
Issue Type: Bug
Components: vsphere-cloud
Reporter: Alexey Larsky
Assignee: Jason Swager

[JIRA] (JENKINS-12115) Aborting a build causes java.lang.StackOverflowError to be thrown in consecutive builds


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

Cletus D'Souza resolved JENKINS-12115.
--

Resolution: Cannot Reproduce

Changed caching from serialized objects to embedded database caching

 Aborting a build causes java.lang.StackOverflowError to be thrown in 
 consecutive builds
 ---

 Key: JENKINS-12115
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12115
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Windows XP, MKS Integrity Client 2009 (Build: 
 4.10.0.5799, Service Pack: 005-01), PTC Integrity Plugin v1.11
Reporter: Simon Tschöke
Assignee: Cletus D'Souza
Priority: Critical
  Labels: exception, plugin

 I have a matrix-build project. The project is tied to 3 slaves (Win XP, Win 
 7, Linux-Ubuntu) on which the project must be build. If I abort the build on 
 one of those slaves the consecutive builds on the same slave fail with a 
 java.lang.StackOverflowError right after checkout from the source-code 
 management system (MKS). Hereby it does not seem to matter how the previous 
 build was aborted. I tested the following causes: manual abortion of 
 build-process, sudden connection breakdown between slave and master.
 Here is the log of a consecutive build that followed an aborted one (some 
 info omitted by [...]):
 {quote}
 Change Log: [...]
 Build Log: [...]
 Preparing to execute si projectinfo for [...]
 Preparing to execute si viewproject for [...]
 Checkout directory is D:\CI\hudson\workspace\[...]
 A clean copy is requested; deleting contents of D:\CI\hudson\workspace\[...]
 Populating clean workspace...
 Successfully checked out 2490 files!
 Saving current Integrity Project configuration...
 FATAL: null
 java.lang.StackOverflowError
   at java.lang.Exception.init(Unknown Source)
   at java.lang.reflect.InvocationTargetException.init(Unknown Source)
   at sun.reflect.GeneratedMethodAccessor459.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
   at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
   at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
   at java.io.ObjectOutputStream.writeObject0(Unknown Source)
   at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
   at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
   at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
   at java.io.ObjectOutputStream.writeObject0(Unknown Source)
   at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
   at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
   at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
   at java.io.ObjectOutputStream.writeObject0(Unknown Source)
   at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
   at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
   at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
   [...]
 {quote}
 The stack trace continues indefinitely.
 Similarly I got the following for a different project where the previous 
 build was aborted as well:
 {quote}
 Change Log: [...]
 Build Log: [...]
 Preparing to execute si projectinfo for [...]
 Preparing to execute si viewproject for [...]
 Checkout directory is D:\CI\hudson\workspace\[...]
 A clean copy is requested; deleting contents of D:\CI\hudson\workspace\[...]
 Populating clean workspace...
 Successfully checked out 628 files!
 Saving current Integrity Project configuration...
 API Response for si viewproject successfully saved to file!
 Successfully saved current Integrity Project configuration to 
 C:\CI\hudson\jobs\[...]
 Writing build change log...
 Change log successfully generated: C:\CI\hudson\jobs\[...]
 FATAL: null
 java.lang.StackOverflowError
   at java.io.ObjectInputStream$PeekInputStream.readFully(Unknown Source)
   at java.io.ObjectInputStream$BlockDataInputStream.readInt(Unknown 
 Source)
   at java.io.ObjectInputStream.readHandle(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)
   [...]
 {quote}
 The stack trace continues indefinitely as well.

--
This message is automatically generated by JIRA.
If you think it

[JIRA] (JENKINS-13632) AbstractMethodError with PTC Integrity Plugin


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

Cletus D'Souza resolved JENKINS-13632.
--

Resolution: Cannot Reproduce

 AbstractMethodError with PTC Integrity Plugin
 -

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

 I get the following error after I upgraded Jenkins as well as the plugin:
 16:51:33  FATAL: 
 com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
 16:51:33  java.lang.AbstractMethodError: 
 com.mks.connect.UserApplicationSessionImpl$SSLSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;ILorg/apache/commons/httpclient/params/HttpConnectionParams;)Ljava/net/Socket;
 16:51:33  at 
 org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
 16:51:33  at 
 org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
 16:51:33  at 
 org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
 16:51:33  at 
 org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
 16:51:33  at 
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
 16:51:33  at 
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.handleHTTPResponse(UserApplicationSessionImpl.java:304)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.getSession(UserApplicationSessionImpl.java:350)
 16:51:33  at 
 com.mks.connect.UserApplicationSessionImpl.getSessionURI(UserApplicationSessionImpl.java:413)
 16:51:33  at 
 com.mks.connect.HttpCmdRunnerImpl.getSessionURI(HttpCmdRunnerImpl.java:72)
 16:51:33  at 
 com.mks.connect.HttpBlimpInputStream.getSessionURI(HttpBlimpInputStream.java:125)
 16:51:33  at 
 com.mks.connect.HttpBlimpInputStream.blimpInitiate(HttpBlimpInputStream.java:152)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.getInputStream(BlimpInputStream.java:223)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.readNoEof(BlimpInputStream.java:693)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.handleNextBlimpCommand(BlimpInputStream.java:266)
 16:51:33  at 
 com.mks.connect.BlimpInputStream.read(BlimpInputStream.java:190)
 When I downgrade to Jenkins 1.419 everything works fine again!

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

[JIRA] (JENKINS-13651) Can't use parameters for existing fitnesse instance: host/port

2012-05-01 Thread peter_schue...@java.net (JIRA)

peter_schuetze created JENKINS-13651:


 Summary: Can't use parameters for existing fitnesse instance: 
host/port
 Key: JENKINS-13651
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13651
 Project: Jenkins
  Issue Type: Bug
  Components: fitnesse
Reporter: peter_schuetze


I added port and server of a remote FitNesse instance as variables (we have 
quite a few FitNesse installations). These don't get resolved. Following the 
stack trace

13:11:49  hudson.plugins.fitnesse.FitnesseBuilder: 
{fitnesseTargetPage=FrontPage.SmokeTests, fitnesseTargetIsSuite=true, 
fitnesseHost=${FitNesse_hostname}, fitnesseHttpTimeout=720, 
fitnessePortRemote=, fitnesseStart=False, 
fitnessePathToXmlResultsOut=fitnesse-results.xml}
13:11:49  Connnecting to 
http://${FitNesse_hostname}/FrontPage.SmokeTests?suiteformat=xml
13:11:49  java.net.UnknownHostException: ${FitNesse_hostname}
13:11:49at java.net.PlainSocketImpl.connect(Unknown Source)
13:11:49at java.net.SocksSocketImpl.connect(Unknown Source)
13:11:49at java.net.Socket.connect(Unknown Source)
13:11:49at java.net.Socket.connect(Unknown Source)
13:11:49at sun.net.NetworkClient.doConnect(Unknown Source)
13:11:49at sun.net.www.http.HttpClient.openServer(Unknown Source)
13:11:49at sun.net.www.http.HttpClient.openServer(Unknown Source)
13:11:49at sun.net.www.http.HttpClient.init(Unknown Source)
13:11:49at sun.net.www.http.HttpClient.New(Unknown Source)
13:11:49at sun.net.www.http.HttpClient.New(Unknown Source)
13:11:49at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
13:11:49at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
13:11:49at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown 
Source)
13:11:49at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
13:11:49at java.net.HttpURLConnection.getResponseCode(Unknown Source)
13:11:49at 
hudson.plugins.fitnesse.FitnesseExecutor.getHttpBytes(FitnesseExecutor.java:218)
13:11:49at 
hudson.plugins.fitnesse.FitnesseExecutor$1.run(FitnesseExecutor.java:197)
13:11:49at java.lang.Thread.run(Unknown Source)
13:11:49  Xml results saved as windows-1252 to 
D:\Hudson\jobs\OCNS_Test_FitNesse\workspace\fitnesse-results.xml

--
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-11549) return changeset integer revision id to environment as well as the node


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

jglick commented on JENKINS-11549:
--

https://github.com/jenkinsci/mercurial-plugin/pull/23 has a better patch, will 
use that.

 return changeset integer revision id to environment as well as the node
 ---

 Key: JENKINS-11549
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11549
 Project: Jenkins
  Issue Type: Improvement
  Components: mercurial, plugin
Affects Versions: current
Reporter: Trevor Baker
Assignee: Kohsuke Kawaguchi
Priority: Minor
 Attachments: hg_revid.patch


 Our builds require the integer revision id {rev} as well as the hash.  The 
 following patch created a new environment variable MERCURIAL_REVISIONID and 
 assigns the {rev} to it.

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

[JIRA] (JENKINS-11549) return changeset integer revision id to environment as well as the node


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

SCM/JIRA link daemon resolved JENKINS-11549.


Resolution: Fixed

 return changeset integer revision id to environment as well as the node
 ---

 Key: JENKINS-11549
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11549
 Project: Jenkins
  Issue Type: Improvement
  Components: mercurial, plugin
Affects Versions: current
Reporter: Trevor Baker
Assignee: Kohsuke Kawaguchi
Priority: Minor
 Attachments: hg_revid.patch


 Our builds require the integer revision id {rev} as well as the hash.  The 
 following patch created a new environment variable MERCURIAL_REVISIONID and 
 assigns the {rev} to it.

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

[JIRA] (JENKINS-11549) return changeset integer revision id to environment as well as the node


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

SCM/JIRA link daemon commented on JENKINS-11549:


Code changed in jenkins
User: Jesse Glick
Path:
 src/main/java/hudson/plugins/mercurial/HgExe.java
 src/main/java/hudson/plugins/mercurial/MercurialSCM.java
 src/main/java/hudson/plugins/mercurial/MercurialTagAction.java
 src/main/resources/hudson/plugins/mercurial/MercurialTagAction/index.jelly
http://jenkins-ci.org/commit/mercurial-plugin/243a424ca3aa792cd6f4b71c59c24b684cd464e4
Log:
  Merge pull request #23 from geofflane/master

[FIXED JENKINS-11549] Add MERCURIAL_CHANGESET_NUMBER to exported environment 
variables


Compare: https://github.com/jenkinsci/mercurial-plugin/compare/6c5a04e...243a424



 return changeset integer revision id to environment as well as the node
 ---

 Key: JENKINS-11549
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11549
 Project: Jenkins
  Issue Type: Improvement
  Components: mercurial, plugin
Affects Versions: current
Reporter: Trevor Baker
Assignee: Kohsuke Kawaguchi
Priority: Minor
 Attachments: hg_revid.patch


 Our builds require the integer revision id {rev} as well as the hash.  The 
 following patch created a new environment variable MERCURIAL_REVISIONID and 
 assigns the {rev} to it.

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

[JIRA] (JENKINS-13292) Problem to update to a tagged revision


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

jglick closed JENKINS-13292.


Resolution: Duplicate

Using tag names in the branch field was never tested or supported. If it 
happened to work in some versions of the plugin, it was by accident.

 Problem to update to a tagged revision
 --

 Key: JENKINS-13292
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13292
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Helen Her
Assignee: Kohsuke Kawaguchi

 In the previous version we were able to clone the remote repository and 
 update it to a tagged revision
 as you can see the log here, v4.6.0.118 it's the tag of the branch r4.6.0.118
 $ hg clone --rev v4.6.0.118 remote_repository_url local_repository
 adding changesets
 adding manifests
 adding file changes
 added 199 changesets with 13401 changes to 6466 files
 updating to branch r4.6.0.118
 But when we updated the plugin to the version 1.38, we couldn't clone the 
 remote repository and update it to a tagged revision
 $ hg clone --rev v4.6.0.118 --noupdate remote_repository_url local_repository
 adding changesets
 adding manifests
 adding file changes
 added 199 changesets with 13401 changes to 6466 files
 [v4.6.0.118] $ hg update --rev v4.6.0.118
 abort: unknown revision 'v4.6.0.118'!
 So we had to downgrade the mercurial plugin to 1.37 for the time being.

--
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-11991) Polling shows changes after job commits and pushes changes


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

jglick closed JENKINS-11991.


Resolution: Duplicate

 Polling shows changes after job commits and pushes changes
 --

 Key: JENKINS-11991
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11991
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Reporter: Jarek Potiuk
Assignee: Kohsuke Kawaguchi

 As of latest version of mercurial plugin (1.38) the behaviour of the plugin 
 changed. We used to make some manuals release jobs to commit some changes 
 (increase build number and set a tag) and push it to the origin repo. It 
 seems that now every time after release job is executed (and commit and push 
 happen), the plugin detects that the repo has changed and triggers another 
 build. It was not working like that before...
 Some outputs:
 1st job (release job run manually):
 21:25:04  [workspace] $ hg showconfig paths.default
 21:25:04  [workspace] $ hg pull --rev 1_0
 21:25:04  [workspace] $ hg update --clean --rev 1_0
 21:25:04  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
 21:25:04  [workspace] $ hg log --rev . --template {node}
 21:25:05  [workspace] $ hg log --rev cc3b37d8df1298eabedfad328cbd4a068e27abf8
 21:25:05  [workspace] $ hg log --template changeset node='{node}' 
 author='{author|xmlescape}' rev='{rev}' 
 date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
  --rev 1_0:0 --follow --prune cc3b37d8df1298eabedfad328cbd4a068e27abf8
 Inside the job:
 hg commit -m Incrementing application version to 1.0-TEST (345 -u 
 b...@polidea.pl AndroidManifest.xml 
 hg tag -f Release_1.0-TEST_345 -u b...@polidea.pl
 hg push 
 Then polling triggers another job:
 21:27:04  Started by an SCM change
 21:27:04  Building on master
 21:27:04  [workspace] $ hg showconfig paths.default
 21:27:04  [workspace] $ hg pull --rev 1_0
 21:27:04  [workspace] $ hg update --clean --rev 1_0
 21:27:04  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
 21:27:04  [workspace] $ hg log --rev . --template {node}
 21:27:05  [workspace] $ hg log --rev cc3b37d8df1298eabedfad328cbd4a068e27abf8
 21:27:05  [workspace] $ hg log --template changeset node='{node}' 
 author='{author|xmlescape}' rev='{rev}' 
 date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
  --rev 1_0:0 --follow --prune cc3b37d8df1298eabedfad328cbd4a068e27abf8

--
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-05-01 Thread ja...@potiuk.com (JIRA)


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

Jarek Potiuk commented on JENKINS-13174:


I am all for this change - it is inddeed the same as JENKINS-11991 . Please fix 
it...

 Stop changeset tags from being counted as a change in Mercurial Plugin polling
 --

 Key: JENKINS-13174
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: Kohsuke Kawaguchi

 We have the slave build machines polling Mercurial repositories, using the 
 Mercurial plugin, to trigger builds.
 During the Jenkins job, we create and push a tag changeset as part of the 
 build process.
 This tag changeset is detected by polling and causing an infinite loop of 
 builds.
 I've looked into other options, I notice the notice away from polling to be 
 more push activated, which sounds good, but it seems this still relies on 
 polling to detect what has changed, so it seems this would still be a problem.
 The other thing that sounded like it may help was modules in the Mercurial 
 plugin, but this is a huge change to move lots of repositories to put 
 everything except the hgtags file into a sub folder and then specify that sub 
 folder as a module.
 If tag changesets were ignorred by polling, similar to a change that was made 
 to ignore merge changesets, all would be good in the world :)

--
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling

2012-05-01 Thread k...@iliumsoft.com (JIRA)


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

Ken Morse commented on JENKINS-13174:
-

If there's any kind of logging we can turn on for this plugin or anything else 
we can do to help track down this problem, please let us know.

 Stop changeset tags from being counted as a change in Mercurial Plugin polling
 --

 Key: JENKINS-13174
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: Kohsuke Kawaguchi

 We have the slave build machines polling Mercurial repositories, using the 
 Mercurial plugin, to trigger builds.
 During the Jenkins job, we create and push a tag changeset as part of the 
 build process.
 This tag changeset is detected by polling and causing an infinite loop of 
 builds.
 I've looked into other options, I notice the notice away from polling to be 
 more push activated, which sounds good, but it seems this still relies on 
 polling to detect what has changed, so it seems this would still be a problem.
 The other thing that sounded like it may help was modules in the Mercurial 
 plugin, but this is a huge change to move lots of repositories to put 
 everything except the hgtags file into a sub folder and then specify that sub 
 folder as a module.
 If tag changesets were ignorred by polling, similar to a change that was made 
 to ignore merge changesets, all would be good in the world :)

--
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-13652) Support workflow steps as build actions and/or post-build notifiers

2012-05-01 Thread jhans...@myyearbook.com (JIRA)

Joe Hansche created JENKINS-13652:
-

 Summary: Support workflow steps as build actions and/or post-build 
notifiers
 Key: JENKINS-13652
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13652
 Project: Jenkins
  Issue Type: New Feature
  Components: jira
Reporter: Joe Hansche
Assignee: Joe Hansche


The [Jira Issue Updater 
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin] 
has a build step that can be used to issue workflow updates as part of a build. 
 Unfortunately that plugin doesn't tie in with the JIRA Plugin, so you must 
manually enter the wsdl URL, username, and password every time the build step 
is used.

Adding a build step would allow the workflow actions to be taken in series with 
an existing job configuration.

Additionally, adding a notifier (post-Recorder, which is how the 
JiraIssueUpdater works), would allow the job to delay updating the workflow 
action until all other recorders have finished (if that is the desire).

--
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-12519) Test Statistic Grid will be rendered diffrently in IE9, Chrome, FF, Opera

2012-05-01 Thread tofuatj...@java.net (JIRA)


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

Thomas Fürer updated JENKINS-12519:
---

Attachment: teststatisticsgrid_FF10.PNG
teststatisticsgrid_IE9.PNG

 Test Statistic Grid will be rendered diffrently in IE9, Chrome, FF, Opera 
 --

 Key: JENKINS-12519
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12519
 Project: Jenkins
  Issue Type: Bug
  Components: dashboard-view
 Environment: jenkins 1.445
 dashboard-view 2.1
 IE 9, FF 4-10, chrome, opera 
Reporter: Thomas Fürer
Assignee: Marco Ambu
Priority: Minor
 Attachments: teststatisticsgrid_FF10.PNG, teststatisticsgrid_IE9.PNG


 The job names are displayed in a centric style in IE9 and opera but are 
 displyed left bounded in FF and chrome.
 I would prefer left bounded.

--
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling


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

SCM/JIRA link daemon commented on JENKINS-13174:


Code changed in jenkins
User: Jesse Glick
Path:
 src/main/java/hudson/plugins/mercurial/MercurialSCM.java
 src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
http://jenkins-ci.org/commit/mercurial-plugin/8d62fa273f7cb0595952a9521ae89abac7b7d606
Log:
  [FIXED JENKINS-13174] Ignore .hgtags changes when polling.






 Stop changeset tags from being counted as a change in Mercurial Plugin polling
 --

 Key: JENKINS-13174
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: Kohsuke Kawaguchi

 We have the slave build machines polling Mercurial repositories, using the 
 Mercurial plugin, to trigger builds.
 During the Jenkins job, we create and push a tag changeset as part of the 
 build process.
 This tag changeset is detected by polling and causing an infinite loop of 
 builds.
 I've looked into other options, I notice the notice away from polling to be 
 more push activated, which sounds good, but it seems this still relies on 
 polling to detect what has changed, so it seems this would still be a problem.
 The other thing that sounded like it may help was modules in the Mercurial 
 plugin, but this is a huge change to move lots of repositories to put 
 everything except the hgtags file into a sub folder and then specify that sub 
 folder as a module.
 If tag changesets were ignorred by polling, similar to a change that was made 
 to ignore merge changesets, all would be good in the world :)

--
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling


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

SCM/JIRA link daemon resolved JENKINS-13174.


Resolution: Fixed

 Stop changeset tags from being counted as a change in Mercurial Plugin polling
 --

 Key: JENKINS-13174
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: Kohsuke Kawaguchi

 We have the slave build machines polling Mercurial repositories, using the 
 Mercurial plugin, to trigger builds.
 During the Jenkins job, we create and push a tag changeset as part of the 
 build process.
 This tag changeset is detected by polling and causing an infinite loop of 
 builds.
 I've looked into other options, I notice the notice away from polling to be 
 more push activated, which sounds good, but it seems this still relies on 
 polling to detect what has changed, so it seems this would still be a problem.
 The other thing that sounded like it may help was modules in the Mercurial 
 plugin, but this is a huge change to move lots of repositories to put 
 everything except the hgtags file into a sub folder and then specify that sub 
 folder as a module.
 If tag changesets were ignorred by polling, similar to a change that was made 
 to ignore merge changesets, all would be good in the world :)

--
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-13653) chmod after publish over ftp

2012-05-01 Thread kalpeshs...@gmail.com (JIRA)

kalpesh soni created JENKINS-13653:
--

 Summary: chmod after publish over ftp
 Key: JENKINS-13653
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13653
 Project: Jenkins
  Issue Type: New Feature
  Components: publish-over-ftp
Affects Versions: current
Reporter: kalpesh soni
Assignee: bap


after publishing php files over ftp, we need them to be chmod to 755

i use clean install, and it resets the permissions, that need to be changed 
manually

can you please provide a checkbox to recursively chmod the dir uploaded with 
permissions specified?

--
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling


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

dogfood commented on JENKINS-13174:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_mercurial #98|http://ci.jenkins-ci.org/job/plugins_mercurial/98/]
 [FIXED JENKINS-13174] Ignore .hgtags changes when polling. (Revision 
8d62fa273f7cb0595952a9521ae89abac7b7d606)

 Result = SUCCESS
Jesse Glick : 
Files : 
* src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
* src/main/java/hudson/plugins/mercurial/MercurialSCM.java


 Stop changeset tags from being counted as a change in Mercurial Plugin polling
 --

 Key: JENKINS-13174
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: Kohsuke Kawaguchi

 We have the slave build machines polling Mercurial repositories, using the 
 Mercurial plugin, to trigger builds.
 During the Jenkins job, we create and push a tag changeset as part of the 
 build process.
 This tag changeset is detected by polling and causing an infinite loop of 
 builds.
 I've looked into other options, I notice the notice away from polling to be 
 more push activated, which sounds good, but it seems this still relies on 
 polling to detect what has changed, so it seems this would still be a problem.
 The other thing that sounded like it may help was modules in the Mercurial 
 plugin, but this is a huge change to move lots of repositories to put 
 everything except the hgtags file into a sub folder and then specify that sub 
 folder as a module.
 If tag changesets were ignorred by polling, similar to a change that was made 
 to ignore merge changesets, all would be good in the world :)

--
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-12544) mercurial generates illegal directory name on Windows


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

SCM/JIRA link daemon resolved JENKINS-12544.


Resolution: Fixed

 mercurial generates illegal directory name on Windows
 -

 Key: JENKINS-12544
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12544
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Windows 2003 R2
 Java 6.0.30
 Jenkins 1.242.2 LTS
 Mercurial plugin 1.38
Reporter: javakoe
Assignee: Kohsuke Kawaguchi
  Labels: plugin, windows

 My local mercurial server runs on port 8000 and the plugin tries to use 
 :8000 in the filename. But : is an illegal character in a filename on 
 Windows.
 Started by user anonymous
 [workspace] $ C:\Program Files\Mercurial\hg.exe showconfig paths.default
 $ C:\Program Files\Mercurial\hg.exe clone --noupdate 
 http://ronaldradial:8000/ 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 abort: The directory name is invalid: 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 ERROR: Failed to clone http://ronaldradial:8000/
 ERROR: Failed to use repository cache for http://ronaldradial:8000/
 [workspace] $ C:\Program Files\Mercurial\hg.exe pull --rev default
 [workspace] $ C:\Program Files\Mercurial\hg.exe update --clean --rev default
 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
 [workspace] $ C:\Program Files\Mercurial\hg.exe --config extensions.purge= 
 clean --all
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev . --template 
 {node}
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev 
 bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --template changeset 
 node='{node}' author='{author|xmlescape}' rev='{rev}' 
 date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
  --rev default:0 --follow --prune bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ cmd /c call 
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\hudson3374063823382421936.bat

--
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-12544) mercurial generates illegal directory name on Windows


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

SCM/JIRA link daemon commented on JENKINS-12544:


Code changed in jenkins
User: Jesse Glick
Path:
 src/main/java/hudson/plugins/mercurial/Cache.java
 src/test/java/hudson/plugins/mercurial/CacheTest.java
http://jenkins-ci.org/commit/mercurial-plugin/fd76cf11527760b2f880ee81ee76a23d1b083079
Log:
  [FIXED JENKINS-12544] Illegal directory name on Windows when port number used 
in URL.


Compare: https://github.com/jenkinsci/mercurial-plugin/compare/8d62fa2...fd76cf1



 mercurial generates illegal directory name on Windows
 -

 Key: JENKINS-12544
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12544
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Windows 2003 R2
 Java 6.0.30
 Jenkins 1.242.2 LTS
 Mercurial plugin 1.38
Reporter: javakoe
Assignee: Kohsuke Kawaguchi
  Labels: plugin, windows

 My local mercurial server runs on port 8000 and the plugin tries to use 
 :8000 in the filename. But : is an illegal character in a filename on 
 Windows.
 Started by user anonymous
 [workspace] $ C:\Program Files\Mercurial\hg.exe showconfig paths.default
 $ C:\Program Files\Mercurial\hg.exe clone --noupdate 
 http://ronaldradial:8000/ 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 abort: The directory name is invalid: 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 ERROR: Failed to clone http://ronaldradial:8000/
 ERROR: Failed to use repository cache for http://ronaldradial:8000/
 [workspace] $ C:\Program Files\Mercurial\hg.exe pull --rev default
 [workspace] $ C:\Program Files\Mercurial\hg.exe update --clean --rev default
 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
 [workspace] $ C:\Program Files\Mercurial\hg.exe --config extensions.purge= 
 clean --all
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev . --template 
 {node}
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev 
 bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --template changeset 
 node='{node}' author='{author|xmlescape}' rev='{rev}' 
 date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
  --rev default:0 --follow --prune bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ cmd /c call 
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\hudson3374063823382421936.bat

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

[JIRA] (JENKINS-12361) Modules with directory separators don't work on Windows


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

jglick resolved JENKINS-12361.
--

Resolution: Fixed

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

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

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

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

[JIRA] (JENKINS-12544) mercurial generates illegal directory name on Windows


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

dogfood commented on JENKINS-12544:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_mercurial #99|http://ci.jenkins-ci.org/job/plugins_mercurial/99/]
 [FIXED JENKINS-12544] Illegal directory name on Windows when port number 
used in URL. (Revision fd76cf11527760b2f880ee81ee76a23d1b083079)

 Result = SUCCESS
Jesse Glick : 
Files : 
* src/main/java/hudson/plugins/mercurial/Cache.java
* src/test/java/hudson/plugins/mercurial/CacheTest.java


 mercurial generates illegal directory name on Windows
 -

 Key: JENKINS-12544
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12544
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Windows 2003 R2
 Java 6.0.30
 Jenkins 1.242.2 LTS
 Mercurial plugin 1.38
Reporter: javakoe
Assignee: Kohsuke Kawaguchi
  Labels: plugin, windows

 My local mercurial server runs on port 8000 and the plugin tries to use 
 :8000 in the filename. But : is an illegal character in a filename on 
 Windows.
 Started by user anonymous
 [workspace] $ C:\Program Files\Mercurial\hg.exe showconfig paths.default
 $ C:\Program Files\Mercurial\hg.exe clone --noupdate 
 http://ronaldradial:8000/ 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 abort: The directory name is invalid: 
 C:\java\hudson\hgcache\DA7E6A4632009859A61A551999EE2109EBB69267-ronaldradial:8000
 ERROR: Failed to clone http://ronaldradial:8000/
 ERROR: Failed to use repository cache for http://ronaldradial:8000/
 [workspace] $ C:\Program Files\Mercurial\hg.exe pull --rev default
 [workspace] $ C:\Program Files\Mercurial\hg.exe update --clean --rev default
 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
 [workspace] $ C:\Program Files\Mercurial\hg.exe --config extensions.purge= 
 clean --all
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev . --template 
 {node}
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --rev 
 bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ C:\Program Files\Mercurial\hg.exe log --template changeset 
 node='{node}' author='{author|xmlescape}' rev='{rev}' 
 date='{date}'msg{desc|xmlescape}/msgadded{file_adds|stringify|xmlescape}/addeddeleted{file_dels|stringify|xmlescape}/deletedfiles{files|stringify|xmlescape}/filesparents{parents}/parents/changeset\n
  --rev default:0 --follow --prune bdd41ba264aa37472c5bf4be6bcb9e46be3c7633
 [workspace] $ cmd /c call 
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\hudson3374063823382421936.bat

--
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-1420) Local repo location string not aggressively normalized

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

jglick resolved JENKINS-1420.
-

Resolution: Duplicate

Possibly resolved by the fix of JENKINS-13400. If the problem persists in the
future, reopen (or file a new bug) and include the portion of the build log
that says ...which looks different than... as that will indicate how to write
a test for the problem.

Local repo location string not aggressively normalized
--

Key: JENKINS-1420
URL: https://issues.jenkins-ci.org/browse/JENKINS-1420
Project: Jenkins
Issue Type: Bug
Components: mercurial
Affects Versions: current
Environment: Platform: All, OS: All
Reporter: medotin
Assignee: jglick
Priority: Minor

This is v1.8 of the Mercurial plugin, and (though I believe it's irrelevant)
1.186 of hudson.
I'm running Hudson on the same machine as my hg repo. I entered the path to
my
repo as /xyz. The first build was fine, but because the cloned repo's hgrc
file
listed the repo location as c:\xyz,
hudson.plugins.mercurial.MercurialSCM.checkout saw these two strings as
different and tried to do a clone instead of an update. It correctly did an
update once I changed my hudson config repo string to c:\xyz to match hgrc.
Perhaps there's some normalization to be done on local repo paths.
On a side note, and I haven't looked into this, when it was trying to do the
clone via first doing a delete, it could not delete the hgrc file (using
Windows). However if I deleted hgrc manually, then ran the build, it deleted
the rest of the stuff just fine. Seems like a bug.

[JIRA] (JENKINS-11368) redmineweb should be a supported repository browser type for all Version Control Systems


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

jglick commented on JENKINS-11368:
--

Speaking for the Mercurial plugin: if you use this service, you are best placed 
to write a browser plugin for it - submit a pull request.

 redmineweb should be a supported repository browser type for all Version 
 Control Systems
 

 Key: JENKINS-11368
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11368
 Project: Jenkins
  Issue Type: Improvement
  Components: bazaar, mercurial
Reporter: Al Budden
Assignee: sdirector
Priority: Minor

 Redmine supports a variety of version control systems (SVN, CVS, Git, 
 Mercurial, Bazaar and Darcs according to the website).  When using the git 
 plugin in Jenkins, among the repository browser options that are available is 
 redmineweb, to point at a redmine repository browser.  Is there any reason 
 why this can't also be offered for Mercurial and Bazaar?  (I haven't checked 
 whether is is offered for SVN, CVS or Darcs).
 I assume this would be extremely simple to implement...

--
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-12404) Mercurial poller triggers new build if workspace doesn't exist

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

jglick resolved JENKINS-12404.
--

Assignee: Willem Verstraeten (was: Kohsuke Kawaguchi)
Resolution: Fixed

Seems to have been fixed in pull request #17 (1.39 plugin), so long as you have
caching enabled. (Without caching it is not possible, since Mercurial has no
commands to extract arbitrary information from a remote repository.)

Mercurial poller triggers new build if workspace doesn't exist
--

Key: JENKINS-12404
URL: https://issues.jenkins-ci.org/browse/JENKINS-12404
Project: Jenkins
Issue Type: Bug
Components: mercurial
Affects Versions: current
Environment: Master: RHEL 6.2 / Jenkins ver. 1.424.2 / Mercurial
plugin 1.38
Slave: Fedora Core 15 i386 / workspaces located on a tmpfs mount
Reporter: Yury Zaytsev
Assignee: Willem Verstraeten

Hi!
I have workspaces on my slaves on tmpfs, so every time I reboot a slave the
workspace, of course, disappears. Now git and svn work totally fine with
that, but mercurial triggers a new build if the workspace doesn't exist and
leaves an entry like that in the polling log:
{quote}
This page captures the polling log that triggered this build.
Started on Jan 12, 2012 10:30:55 PM
No workspace is available, so can't check for updates.
Scheduling a new build to get a workspace.
Done. Took 14 ms
Changes found
{quote}
This is very annoying, because sometimes I need to reboot the slaves to apply
kernel updates etc. and tmpfs is just so much faster than using a
non-volatile memory.

[JIRA] (JENKINS-13329) Mercurial debug causes clone repository each time Mrather than update


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

Work on JENKINS-13329 started by Kohsuke Kawaguchi.

 Mercurial debug causes clone repository each time Mrather than update
 -

 Key: JENKINS-13329
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13329
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Linux, Jenkis 1.458, mercurial 1.7
Reporter: Vladimir Kralik
Assignee: Kohsuke Kawaguchi
Priority: Minor

 JENKINS-4672 gives possibility to setup Marcurial debug flag.
 When I switch it on, the all mercurial call is done with option --debug.
 The first command, during the build, checks if configuration of repository 
 wasn't changed.
 This check is done by comparision result of commad hg showconfig 
 paths.default with jenkins configuration.
 But there is a different output if the debug option is ON.
 Without debug option : 
  $ hg showconfig paths.default
  https://hg/hg/zpis
 With debug option : 
  hg --debug showconfig paths.default
  read config from: /etc/mercurial/hgrc
  read config from: /data/hudson/.hgrc
  none: https://hg/hg/zpis
 So with the debug option, the mercurial configuration is always different as 
 jenkins configuration.
 Result is : 
 ---
 Building in workspace /data/hudson/jobs/vlk-pokus/workspace
 [workspace] $ hg --debug showconfig paths.default
 read config from: /etc/mercurial/hgrc
 read config from: /data/hudson/.hgrc
 none: https://hg/hg/zpis
 which looks different than https://hg/hg/zpis
 so falling back to fresh clone rather than incremental update
 Workaround : Switch off the degug option.

--
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-13589) Erroneous calculation of threshold crossing


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

SCM/JIRA link daemon commented on JENKINS-13589:


Code changed in jenkins
User: Gregory Boissinot
Path:
 src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java
http://jenkins-ci.org/commit/cppcheck-plugin/2c22881a62bd4bd4fa8797cdc7cd8d2afc92f868
Log:
  Fix JENKINS-13589






 Erroneous calculation of threshold crossing
 ---

 Key: JENKINS-13589
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13589
 Project: Jenkins
  Issue Type: Bug
  Components: cppcheck
Affects Versions: current
Reporter: Alexandr Penzai
Assignee: gbois
Priority: Minor

 There is a typo in
 https://github.com/jenkinsci/cppcheck-plugin/blob/master/src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java#L211
 as result plugin incorrectly calculates total amount of errors
 {noformat}
 - nbErrors = this.getReport().getWarningSeverityList().size();
 + nbErrors = nbErrors + this.getReport().getWarningSeverityList().size();
 {noformat}
 and for previous errors
 https://github.com/jenkinsci/cppcheck-plugin/blob/master/src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java#L213
 {noformat}
 - nbPreviousError = 
 previousResult.getReport().getWarningSeverityList().size();
 + nbPreviousError = nbPreviousError + 
 previousResult.getReport().getWarningSeverityList().size();
 {noformat}
 Please correct. 

--
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-13589) Erroneous calculation of threshold crossing


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

gbois resolved JENKINS-13589.
-

Resolution: Fixed

Thank you so much to report it.
Fixed

 Erroneous calculation of threshold crossing
 ---

 Key: JENKINS-13589
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13589
 Project: Jenkins
  Issue Type: Bug
  Components: cppcheck
Affects Versions: current
Reporter: Alexandr Penzai
Assignee: gbois
Priority: Minor

 There is a typo in
 https://github.com/jenkinsci/cppcheck-plugin/blob/master/src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java#L211
 as result plugin incorrectly calculates total amount of errors
 {noformat}
 - nbErrors = this.getReport().getWarningSeverityList().size();
 + nbErrors = nbErrors + this.getReport().getWarningSeverityList().size();
 {noformat}
 and for previous errors
 https://github.com/jenkinsci/cppcheck-plugin/blob/master/src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java#L213
 {noformat}
 - nbPreviousError = 
 previousResult.getReport().getWarningSeverityList().size();
 + nbPreviousError = nbPreviousError + 
 previousResult.getReport().getWarningSeverityList().size();
 {noformat}
 Please correct. 

--
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-6384) SCons plugin doesn't support multi-configuration project.


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

Work on JENKINS-6384 started by gbois.

 SCons plugin doesn't support multi-configuration project.
 -

 Key: JENKINS-6384
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6384
 Project: Jenkins
  Issue Type: Bug
  Components: scons
Affects Versions: current
Reporter: basharimovvv
Assignee: gbois

 I've tried to configure multi-configuration project in hudson and set invoke 
 scons script as a build step. But i discovered that the environment variable 
 passed by configuration matrix is not available in scons script.
 Afterwards i used
 {{cmd.exe /C scons -c msver=7.1 compiler=%compiler% debug=%debug%  exit 
 %%ERRORLEVEL%%}}
 to run scons script and everything went well.

--
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-6384) SCons plugin doesn't support multi-configuration project.


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

gbois commented on JENKINS-6384:


Hi,thanks for reporting this issue.

Please could you attach your job configuration file (config.xml).
I'll try to get more information with it and reproduce the problem.

 SCons plugin doesn't support multi-configuration project.
 -

 Key: JENKINS-6384
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6384
 Project: Jenkins
  Issue Type: Bug
  Components: scons
Affects Versions: current
Reporter: basharimovvv
Assignee: gbois

 I've tried to configure multi-configuration project in hudson and set invoke 
 scons script as a build step. But i discovered that the environment variable 
 passed by configuration matrix is not available in scons script.
 Afterwards i used
 {{cmd.exe /C scons -c msver=7.1 compiler=%compiler% debug=%debug%  exit 
 %%ERRORLEVEL%%}}
 to run scons script and everything went well.

--
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-13329) Mercurial debug causes clone repository each time Mrather than update


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

SCM/JIRA link daemon resolved JENKINS-13329.


Resolution: Fixed

 Mercurial debug causes clone repository each time Mrather than update
 -

 Key: JENKINS-13329
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13329
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Linux, Jenkis 1.458, mercurial 1.7
Reporter: Vladimir Kralik
Assignee: Kohsuke Kawaguchi
Priority: Minor

 JENKINS-4672 gives possibility to setup Marcurial debug flag.
 When I switch it on, the all mercurial call is done with option --debug.
 The first command, during the build, checks if configuration of repository 
 wasn't changed.
 This check is done by comparision result of commad hg showconfig 
 paths.default with jenkins configuration.
 But there is a different output if the debug option is ON.
 Without debug option : 
  $ hg showconfig paths.default
  https://hg/hg/zpis
 With debug option : 
  hg --debug showconfig paths.default
  read config from: /etc/mercurial/hgrc
  read config from: /data/hudson/.hgrc
  none: https://hg/hg/zpis
 So with the debug option, the mercurial configuration is always different as 
 jenkins configuration.
 Result is : 
 ---
 Building in workspace /data/hudson/jobs/vlk-pokus/workspace
 [workspace] $ hg --debug showconfig paths.default
 read config from: /etc/mercurial/hgrc
 read config from: /data/hudson/.hgrc
 none: https://hg/hg/zpis
 which looks different than https://hg/hg/zpis
 so falling back to fresh clone rather than incremental update
 Workaround : Switch off the degug option.

--
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-13329) Mercurial debug causes clone repository each time Mrather than update


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

SCM/JIRA link daemon commented on JENKINS-13329:


Code changed in jenkins
User: Jesse Glick
Path:
 src/main/java/hudson/plugins/mercurial/HgExe.java
 src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
http://jenkins-ci.org/commit/mercurial-plugin/2dadbc8944937ad3a00fe5c82ef2584f71d26e31
Log:
  [FIXED JENKINS-13329] --debug triggered fresh clones rather than updates.


Compare: https://github.com/jenkinsci/mercurial-plugin/compare/fd76cf1...2dadbc8



 Mercurial debug causes clone repository each time Mrather than update
 -

 Key: JENKINS-13329
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13329
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Affects Versions: current
 Environment: Linux, Jenkis 1.458, mercurial 1.7
Reporter: Vladimir Kralik
Assignee: Kohsuke Kawaguchi
Priority: Minor

 JENKINS-4672 gives possibility to setup Marcurial debug flag.
 When I switch it on, the all mercurial call is done with option --debug.
 The first command, during the build, checks if configuration of repository 
 wasn't changed.
 This check is done by comparision result of commad hg showconfig 
 paths.default with jenkins configuration.
 But there is a different output if the debug option is ON.
 Without debug option : 
  $ hg showconfig paths.default
  https://hg/hg/zpis
 With debug option : 
  hg --debug showconfig paths.default
  read config from: /etc/mercurial/hgrc
  read config from: /data/hudson/.hgrc
  none: https://hg/hg/zpis
 So with the debug option, the mercurial configuration is always different as 
 jenkins configuration.
 Result is : 
 ---
 Building in workspace /data/hudson/jobs/vlk-pokus/workspace
 [workspace] $ hg --debug showconfig paths.default
 read config from: /etc/mercurial/hgrc
 read config from: /data/hudson/.hgrc
 none: https://hg/hg/zpis
 which looks different than https://hg/hg/zpis
 so falling back to fresh clone rather than incremental update
 Workaround : Switch off the degug option.

--
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-12409) please add a way to set a process environment variable in the Jenkins scons build step


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

gbois resolved JENKINS-12409.
-

Resolution: Fixed

I think the EnvInject plugin 
(https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin) should fix your 
issue.

 please add a way to set a process environment variable in the Jenkins scons 
 build step
 --

 Key: JENKINS-12409
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12409
 Project: Jenkins
  Issue Type: New Feature
  Components: scons
Reporter: Jason Sachs
Assignee: gbois

 I have a need to set environment variables specific to a scons build step. It 
 is not used by Sconstruct itself, but by a python library which I call from 
 scons, that accesses the environment variables. 
 It needs to be outside the SConstruct file itself, because I use the same 
 scons project outside of jenkins for manual builds.
 I have no way of accomplishing this, except to manage the global Jenkins 
 configuration itself.
 (I'm also going to put in a request for this to be added at the Jenkins job 
 level; it'd be nice if it could be added to the build step level for all 
 types of build steps, but that seems like it might be hard because they are 
 so different.)

--
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-13457) support for hg flow


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

jglick commented on JENKINS-13457:
--

This request is more specific and idiosyncratic than what the Mercurial plugin 
generally can support. Would need to be in its own plugin. The architectural 
question then is what can be programmatically reused from the basic Hg plugin. 
Can you create an {{SCM}} on the fly for a job and do some polling/updates/etc. 
with it? Or do you need to define your own {{SCM}} which delegates some 
functions?

(JENKINS-11102 would cover some of the basic parts of this request.)

 support for hg flow 
 

 Key: JENKINS-13457
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13457
 Project: Jenkins
  Issue Type: New Feature
  Components: mercurial
Reporter: Joe Passavanti
Assignee: Kohsuke Kawaguchi
  Labels: hgflow, mercurial

 hg flow (https://bitbucket.org/yinwm/hgflow/wiki/Home) adds process control 
 in Mercurial similar to git flow (https://github.com/nvie/gitflow).  One of 
 the outcomes of this process is that it creates and deletes branches all the 
 time.
 For example: the releases branch in itself really doesn't have anything in 
 it.  In our process, we have mapped this to staging, so that, when we create 
 a release, hg flow will create a branch under releases with whatever name we 
 come up with.  example: releases/rel_12
 Once we deem this release as tested and ready to go live, hg flow will then 
 merge it into the default (sometimes known as master) branch, which is where 
 we then push out to our servers for production.
 It would be nice, if the Jenkins Mercurial plugin could help match this 
 process.  As it is today, when we create a new release, I have Jenkins set up 
 with a parameter for the job, that we have to type in the current release 
 branch every time we push an update. It would be nice if there could a 
 checkbox or job config that would tell jenkins which of the top branches to 
 monitor (releases,default,develop, etc.).  Then the process would go as:
 # query hg branches and look for any branches under the branch named in the 
 above config variable
 ## if its the releases branch, there should always only be 0 or 1 according 
 to hg flow
 ## if 0, nothing for jenkins to do
 ## if more than 1, some kind of process problem, jenkins shouldn't continue
 # assuming there is a branch under releases, switch to it
 # run hg update on the branch
 ## if there are updates, process updates, run rest of job, capture the branch 
 name (example: rel_15 for the branch releases/rel_15) and allow it to be a 
 variable for post build actions (example: to be used with Jira plugin to tag 
 tickets with the release branch for Jira changelog)
 ## if not, don't process rest of 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-10912) Memory leak (?) in dashboard

2012-05-01 Thread akarol...@wurldtech.com (JIRA)


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

Anoop Karollil edited comment on JENKINS-10912 at 5/1/12 9:21 PM:
--

We are seeing this problem too. Over time Jenkins uses about 700MB for about 10 
jobs. The 'Monitoring' plugin (quite useful by the way) lets you do a garbage 
collection but that cleared up only 30MB. The histogram shows about 150MB usage 
over the past week and then a quick ramp yesterday from 150MB to 700MB. There 
was a jump in number of sessions from 3 to 9 around the time just before the 
ramping in memory usage happened. I am not sure if its related and the number 
of sessions dropped to 4 a bit after. CPU usage is also quite high right now, 
mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1

  was (Author: akarollil):
We are seeing this problem too. Over time Jenkins uses about 700MB for 
about 10 jobs. The 'Monitoring' plugin (quite useful by the way) lets you do a 
garbage collection but that cleared up only 30MB. The histogram shows about 
150MB usage over the past week and then a quick ramp yesterday from 150MB to 
700MB. There was a jump in number of sessions from 3 to 9 around the time just 
before the ramping in memory usage happened. I am not sure if its related. CPU 
usage is also quite high right now, mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1
  
 Memory leak (?) in dashboard
 

 Key: JENKINS-10912
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10912
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: windows jenkins server
 windows client
 chrome browser
 autorefresh is enabled
Reporter: david abadir
Priority: Minor

 leaving the dashboard webpage open (with autorefresh) will accumulate lots of 
 memory.  I left it open over the weekend and it was using over 700 MB of ram! 
  you can watch the memory consumption increase ~3-10 MB every time it 
 refreshes (manually or automatically).  Sometimes it will decrease to the 
 pre-refreshed amount, but it will always increase over time (instantaneous 
 readings may/may not prove true, but long term averages will).

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

[JIRA] (JENKINS-10912) Memory leak (?) in dashboard

2012-05-01 Thread akarol...@wurldtech.com (JIRA)


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

Anoop Karollil edited comment on JENKINS-10912 at 5/1/12 9:31 PM:
--

We are seeing this problem too. Over time Jenkins uses about 700MB for about 10 
jobs. The 'Monitoring' plugin (quite useful by the way) lets you do a garbage 
collection but that cleared up only 30MB. The histogram shows about 150MB usage 
over the past week and then a quick ramp yesterday from 150MB to 700MB. There 
was a jump in number of sessions from 3 to 9 around the time just before the 
ramping in memory usage happened. I am not sure if its related and the number 
of sessions dropped to 4 a bit after. CPU usage is also quite high right now, 
mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1


We recently switched from using Jetty as a container for Jenkins to Winstone. 
But again, I don't know if that is relevant.

  was (Author: akarollil):
We are seeing this problem too. Over time Jenkins uses about 700MB for 
about 10 jobs. The 'Monitoring' plugin (quite useful by the way) lets you do a 
garbage collection but that cleared up only 30MB. The histogram shows about 
150MB usage over the past week and then a quick ramp yesterday from 150MB to 
700MB. There was a jump in number of sessions from 3 to 9 around the time just 
before the ramping in memory usage happened. I am not sure if its related and 
the number of sessions dropped to 4 a bit after. CPU usage is also quite high 
right now, mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1
  
 Memory leak (?) in dashboard
 

 Key: JENKINS-10912
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10912
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: windows jenkins server
 windows client
 chrome browser
 autorefresh is enabled
Reporter: david abadir
Priority: Minor

 leaving the dashboard webpage open (with autorefresh) will accumulate lots of 
 memory.  I left it open over the weekend and it was using over 700 MB of ram! 
  you can watch the memory consumption increase ~3-10 MB every time it 
 refreshes (manually or automatically).  Sometimes it will decrease to the 
 pre-refreshed amount, but it will always increase over time (instantaneous 
 readings may/may not prove true, but long term averages will).

--
This message is

[JIRA] (JENKINS-13624) BitBucket URL not validated for format


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

jglick updated JENKINS-13624:
-

Summary: BitBucket URL not validated for format  (was: When using bitbucket 
as a code browser, links to changeset are incorrect)

 BitBucket URL not validated for format
 --

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

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

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

[JIRA] (JENKINS-7496) Perforce plugin does not sync paths with space in them, removing these lines from the generated view

2012-05-01 Thread kancharl...@yahoo.com (JIRA)

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

Srini Kancharla commented on JENKINS-7496:
--

This bug still exists in the p4 plugin version 1.3.13.
I have path mapping similiar to
//depot/Projects/My Project/... //proj_deploy_jenkins/...

and I get an error
Warning: Client Spec line invalid, ignoring. (//depot/Projects/My Project/...
//proj_deploy_jenkins/...

I will try and fix this issue if noone wants to pick this up.

Perforce plugin does not sync paths with space in them, removing these lines
from the generated view

Key: JENKINS-7496
URL: https://issues.jenkins-ci.org/browse/JENKINS-7496
Project: Jenkins
Issue Type: Bug
Components: perforce
Affects Versions: current
Environment: Windows 7
Reporter: ssbarnea
Assignee: Rob Petti
Fix For: current

Perforce plugin will not sync paths with space in their names.
Example:
//aaa/bbb/... //hudson_{{JOB_NAME}}/aaa/bbb ccc/...
This will give an error in the config UI but even if you save it it will fail
to sync.
I checked and in the final workspace(clientspec) this line will be missing
and as a side effect the workspace will miss some files.
This is a major issue considering that there is no workaround for it, making
the plugin useless if you are unlucky to have to use spaces in directory
names.

[JIRA] (JENKINS-10912) Memory leak (?) in dashboard

2012-05-01 Thread akarol...@wurldtech.com (JIRA)


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

Anoop Karollil edited comment on JENKINS-10912 at 5/1/12 9:33 PM:
--

We are seeing this problem too (on v1.461). Over time Jenkins uses about 700MB 
for about 10 jobs. The 'Monitoring' plugin (quite useful by the way) lets you 
do a garbage collection but that cleared up only 30MB. The histogram shows 
about 150MB usage over the past week and then a quick ramp yesterday from 150MB 
to 700MB. There was a jump in number of sessions from 3 to 9 around the time 
just before the ramping in memory usage happened. I am not sure if its related 
and the number of sessions dropped to 4 a bit after. CPU usage is also quite 
high right now, mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1


We recently switched from using Jetty as a container for Jenkins to Winstone. 
But again, I don't know if that is relevant.

  was (Author: akarollil):
We are seeing this problem too. Over time Jenkins uses about 700MB for 
about 10 jobs. The 'Monitoring' plugin (quite useful by the way) lets you do a 
garbage collection but that cleared up only 30MB. The histogram shows about 
150MB usage over the past week and then a quick ramp yesterday from 150MB to 
700MB. There was a jump in number of sessions from 3 to 9 around the time just 
before the ramping in memory usage happened. I am not sure if its related and 
the number of sessions dropped to 4 a bit after. CPU usage is also quite high 
right now, mostly tying down one CPU core.

Memory histogram shows this:

Class Size (Kb) % size Instances % instances
byte[]  132,623 17  179,202 1
char[]  125,861 16  1,630,859   9
java.util.HashMap$Entry 65,111  8   2,778,092   16   
java.util.HashMap$Entry[]   51,225  6   700,897 4
java.lang.String43,672  5   1,863,370   11   
java.lang.Object[]  30,612  4   453,476 2
java.util.WeakHashMap$Entry 28,414  3   727,415 4
java.util.HashMap   27,029  3   691,947 4
java.util.WeakHashMap$Entry[]   19,986  2   194,526 1
java.util.Hashtable$Entry[] 17,852  2   311,216 1
java.util.Hashtable 11,176  1   286,110 1
java.util.WeakHashMap   9,118   1   194,526 1
org.apache.commons.jelly.JellyContext   8,378   1   214,498 1   
storage/sw/hudson/war/WEB-INF/lib/commons-jelly-1.1-jenkins-20110627.jar
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1  8,090   1   115,058 
0   storage/sw/hudson/war/WEB-INF/lib/stapler-jelly-1.187.jar
java.lang.String[]  7,711   1   174,016 1
java.util.ArrayList 7,655   1   326,640 1


We recently switched from using Jetty as a container for Jenkins to Winstone. 
But again, I don't know if that is relevant.
  
 Memory leak (?) in dashboard
 

 Key: JENKINS-10912
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10912
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: windows jenkins server
 windows client
 chrome browser
 autorefresh is enabled
Reporter: david abadir
Priority: Minor

 leaving the dashboard webpage open (with autorefresh) will accumulate lots of 
 memory.  I left it open over the weekend and it was using over 700 MB of ram! 
  you can watch the memory consumption increase ~3-10 MB every time it 
 refreshes (manually or automatically).  Sometimes it will decrease to the 
 pre-refreshed amount, but it

[JIRA] (JENKINS-13624) BitBucket URL not validated for format


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

SCM/JIRA link daemon resolved JENKINS-13624.


Resolution: Fixed

 BitBucket URL not validated for format
 --

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

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

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

[JIRA] (JENKINS-7496) Perforce plugin does not sync paths with space in them, removing these lines from the generated view

2012-05-01 Thread rob.pe...@gmail.com (JIRA)


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

Rob Petti commented on JENKINS-7496:


Srini, quote both parts:
//depot/Projects/My Project/... //proj_deploy_jenkins/...

I'll fix this issue for the next release.

 Perforce plugin does not sync paths with space in them, removing these lines 
 from the generated view
 

 Key: JENKINS-7496
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7496
 Project: Jenkins
  Issue Type: Bug
  Components: perforce
Affects Versions: current
 Environment: Windows 7
Reporter: ssbarnea
Assignee: Rob Petti
 Fix For: current


 Perforce plugin will not sync paths with space in their names.
 Example:
 //aaa/bbb/... //hudson_{{JOB_NAME}}/aaa/bbb ccc/...
 This will give an error in the config UI but even if you save it it will fail 
 to sync.
 I checked and in the final workspace(clientspec) this line will be missing 
 and as a side effect the workspace will miss some files.
 This is a major issue considering that there is no workaround for it, making 
 the plugin useless if you are unlucky to have to use spaces in directory 
 names.

--
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-7496) Perforce plugin does not sync paths with space in them, removing these lines from the generated view


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

dogfood commented on JENKINS-7496:
--

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_perforce #223|http://ci.jenkins-ci.org/job/plugins_perforce/223/]
 [FIXED JENKINS-7496] fix quoting issue in view parsing (Revision 
d5ba5f9e1cae2ea613f2ddfc3714067c91789698)

 Result = SUCCESS
Rob Petti : 
Files : 
* src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
* src/main/java/hudson/plugins/perforce/PerforceSCM.java


 Perforce plugin does not sync paths with space in them, removing these lines 
 from the generated view
 

 Key: JENKINS-7496
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7496
 Project: Jenkins
  Issue Type: Bug
  Components: perforce
Affects Versions: current
 Environment: Windows 7
Reporter: ssbarnea
Assignee: Rob Petti
 Fix For: current


 Perforce plugin will not sync paths with space in their names.
 Example:
 //aaa/bbb/... //hudson_{{JOB_NAME}}/aaa/bbb ccc/...
 This will give an error in the config UI but even if you save it it will fail 
 to sync.
 I checked and in the final workspace(clientspec) this line will be missing 
 and as a side effect the workspace will miss some files.
 This is a major issue considering that there is no workaround for it, making 
 the plugin useless if you are unlucky to have to use spaces in directory 
 names.

--
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-13654) Showing attributes in testng results

2012-05-01 Thread jaypatel...@gmail.com (JIRA)

Jay Patel created JENKINS-13654:
---

 Summary: Showing attributes in testng results
 Key: JENKINS-13654
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13654
 Project: Jenkins
  Issue Type: Improvement
  Components: testng
Reporter: Jay Patel
Assignee: nalin_makar


As of now, if we have any attributes being set on testng-results.xml file, we 
cannot see them on jenkins build reports. It would be really nice, if the table 
representation of testng test results can incorporate those attributes.

--
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-13552) Provide extended 'injected environment variables' view


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

gbois commented on JENKINS-13552:
-

With the EnvInject plugin, environment variables are injected at runtime.
Reporting environment variables are post build.
For matrix jobs, there is a dedicated report on each configuration and there is 
not inheritance from the parent job.

Knowing  if a environment variable has been injected as a pre build or as a 
build step is not so important for me.
Could you give more use cases?

 Provide extended 'injected environment variables' view
 --

 Key: JENKINS-13552
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13552
 Project: Jenkins
  Issue Type: New Feature
  Components: envinject
Reporter: Marcel Huber
Assignee: gbois

 Especially in multi configuration jobs and master/slave environments, it is 
 sometimes difficult to examine where an injected value comes from and 
 probably why it is different to our expectation.
 I guess a UI containing an env location matrix would help to figure out the 
 origin of a value.
 Example:
 |Variable name | injected value  | injected from | masters value | 
 propertiesfile value | slave value | groovy script | ... |
 |HOME  | /var/lib/jenins | slave | /home/jenkins | -- | 
 /var/lib/jenkins | -- | ... |
 |...| | | | | | | |
 I could also think of such a matrix as a help for configuration when you 
 don't actually know all parties potentially injecting values for a variable.

--
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-13552) Provide extended 'injected environment variables' view


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

Work on JENKINS-13552 started by gbois.

 Provide extended 'injected environment variables' view
 --

 Key: JENKINS-13552
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13552
 Project: Jenkins
  Issue Type: New Feature
  Components: envinject
Reporter: Marcel Huber
Assignee: gbois

 Especially in multi configuration jobs and master/slave environments, it is 
 sometimes difficult to examine where an injected value comes from and 
 probably why it is different to our expectation.
 I guess a UI containing an env location matrix would help to figure out the 
 origin of a value.
 Example:
 |Variable name | injected value  | injected from | masters value | 
 propertiesfile value | slave value | groovy script | ... |
 |HOME  | /var/lib/jenins | slave | /home/jenkins | -- | 
 /var/lib/jenkins | -- | ... |
 |...| | | | | | | |
 I could also think of such a matrix as a help for configuration when you 
 don't actually know all parties potentially injecting values for a variable.

--
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-13654) Showing attributes in testng results

2012-05-01 Thread nalin_ma...@java.net (JIRA)


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

nalin_makar commented on JENKINS-13654:
---

Hi Jay,

Please attach a sample testng XML file that we can work with.

Thanks.

 Showing attributes in testng results
 

 Key: JENKINS-13654
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13654
 Project: Jenkins
  Issue Type: Improvement
  Components: testng
Reporter: Jay Patel
Assignee: nalin_makar

 As of now, if we have any attributes being set on testng-results.xml file, we 
 cannot see them on jenkins build reports. It would be really nice, if the 
 table representation of testng test results can incorporate those attributes.

--
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-13556) Unprintable character in executor name in JSON API output

2012-05-01 Thread fmer...@qualcomm.com (JIRA)

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

Frank Merrow commented on JENKINS-13556:

I have also seen this issue on our Jenkins systems . . .

NOTE: This is NOT a plugin issue . . . this can be duplicated on a virgin
Jenkins . . . just fill up all the executors with Jobs and then queue something
so you get the Waiting for next available executor on . (Typically means you
had to node lock a job.)

Easy to duplicate (for me 100% in 1.459 and 1.460) Never happens on a Jenkins
where none of the jobs are node locked, always happens on Jenkins where the
jobs are node locked. As discussed above, affects both the GUI and the JSON
return values if using Jenkins/Python).

Frank

Unprintable character in executor name in JSON API output
-

Key: JENKINS-13556
URL: https://issues.jenkins-ci.org/browse/JENKINS-13556
Project: Jenkins
Issue Type: Bug
Components: jenkinswalldisplay
Affects Versions: current
Reporter: Chad Myers

After upgrading to the 1.460 version of Jenkins, we noticed that when a build
was waiting for an executor, if you hovered over the build in the wall
display, it would say Waiting for next available executor on
[ESC][8mha:iR+LCABb85aBtbiIQSajNKU4P08vOT+vOD8nVc+jsiC1KCczL9svvyT1dMUiOWdZ/mImBiZPBrac1Lz0kgwfBubSopwSBiGfrMSyRP2cxLx0/eCSosy8dOuKIgYpNOOcITTIMAYIYGRiYKgoALFKGLj0k/NzC0pLUov0ATz5UcyP[ESC][0m
The [ESC] was actually the ASCII/ANSI escape character 0x1B.
When we attempt to use the JSON API to get the status of builds, our script
(Ruby) fails to parse the JSON due to invalid escape characters in the string:
why:Waiting for next available executor on
[8mha:iR+LCABb85aBtbiIQSajNKU4P08vOT+vOD8nVc+jsiC1KCczL9svvyT1dMUiOWdZ/mImBiZPBrac1Lz0kgwfBubSopwSBiGfrMSyRP2cxLx0/eCSosy8dOuKIgYpNOOcITTIMAYIYGRiYKgoALFKGLj0k/NzC0pLUov0ATz5UcyP[0m
Before the [8mha and the [0m there is the invisible 0x1B escape character.
When we click on the waiting build in the UI to view the build details, it
says (correctly) #1849(pending - Waiting for next available executor on
master )
master is the name of our primary build server/executor.
I have no idea where the big [8mhz:iR... stuff is coming from.

[JIRA] (JENKINS-3912) support for both client cert username/password auth to SVN

2012-05-01 Thread dustin.a.par...@gmail.com (JIRA)


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

Dustin Parker commented on JENKINS-3912:


Hate to me too, but we're running up against this problem, too on Jenkins 
1.462, SVN plugin 1.39. Specifying username/password gives an NPE, specifying 
certificate gives 401 just like the commenter above. I'd love for this bug to 
be fixed, but is there any way I can work around this problem for now? Some 
combination of environment variables and editing configuration files that'll 
get Jenkins+SVNKit to use the credentials and certificate file?

 support for both client cert  username/password auth to SVN
 

 Key: JENKINS-3912
 URL: https://issues.jenkins-ci.org/browse/JENKINS-3912
 Project: Jenkins
  Issue Type: Improvement
  Components: subversion
Affects Versions: current
 Environment: Platform: All, OS: Windows XP
Reporter: jrissone
Priority: Critical

 I have a need to use two authentication methods (HTTPS client certs and 
 username/password) for access to the SVN server. Aside from the additional 
 security provided by having username/pw on the SVN repo, it is useful to 
 control authorization permissions by user with a username/pw for each 
 acccount 
 accessing the repo. Since Hudson uses radio buttons to select the SVN 
 authentication options, it does not appear to be possible to use both and 
 have 
 it connect to the SVN repository without removing one of the authentication 
 measures currently in place.
 If there is not a plugin that addresses this case, it would be helpful if 
 Hudson supported multiple authentication options (or at least those two).

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

[JIRA] (JENKINS-13264) fail checkout 2 modules with different path

2012-05-01 Thread agent...@yahoo.com (JIRA)


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

James Gustafson commented on JENKINS-13264:
---

Can such an option be added? What would the difference be from what the Legacy 
mode option is supposed to do? I have the same issue as the OP except with one 
module with a bunch of legacy directories. The Legacy mode doesn't work with 
the 2.x CVS plug-in. And I get the same error as the OP if I try to set the 
Local Name to the same path as the Remote Name. Thanks.

 fail checkout 2 modules with different path
 ---

 Key: JENKINS-13264
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13264
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
 Environment: linux
Reporter: Eric Co

 I create two cvs modules with the path
   lib/flac-1.2.1
   drv/linux/fuse
 when it check out, got the error:
   cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 
 lib/flac-1.2.1 
   cvs [checkout aborted]: could not change directory to requested checkout 
 directory `lib': No such file or directory

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

[JIRA] (JENKINS-13537) Not perform revert snapshot for all vmwares of a label