date:20120420


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

SCM/JIRA link daemon commented on JENKINS-10880:


Code changed in jenkins
User: Marc Guenther
Path:
 core/src/main/java/hudson/triggers/SCMTrigger.java
http://jenkins-ci.org/commit/jenkins/7066daf3ee9d75d427918b068293e5b4ebbc98cd
Log:
  [JENKINS-10880] output the job when polling fails

When polling fails for some reason, it simply outputs
Failed to record SCM polling which is not very helpful.
At least add the job, like it is done already in the thread name:
Failed to record SCM polling for +job




 Git plugin fails on remote Poll
 ---

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

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

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

[JIRA] (JENKINS-10880) Git plugin fails on remote Poll

2012-04-20 Thread michael.ha...@thomsonreuters.com (JIRA)


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

SCM/JIRA link daemon commented on JENKINS-10880:


Code changed in jenkins
User: Seiji Sogabe
Path:
 core/src/main/java/hudson/triggers/SCMTrigger.java
http://jenkins-ci.org/commit/jenkins/f338e21b4f00d66f14b83af3f0c91a9ac15d8513
Log:
  Merge pull request #433 from marc-guenther/jenkins-10880

[JENKINS-10880] output the job when polling fails


Compare: https://github.com/jenkinsci/jenkins/compare/d98926a...f338e21



 Git plugin fails on remote Poll
 ---

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

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

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

[JIRA] (JENKINS-13003) HTTP 500 on import causes NullPointerException

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


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

jieryn resolved JENKINS-13003.
--

Resolution: Duplicate

JENKINS-11185

 HTTP 500 on import causes NullPointerException
 --

 Key: JENKINS-13003
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13003
 Project: Jenkins
  Issue Type: Bug
  Components: job-import
Affects Versions: current
Reporter: Arvind Ramalingam
Assignee: jieryn

 FAILED - Server returned HTTP response code: 403 when trying to use import 
 plugin to import jobs from one Jenkins to another.
 It redirects me to the below stack trace.
 HTTP Status 500 -
 type Exception report
 message
 description The server encountered an internal error () that prevented it 
 from fulfilling this request.
 exception
 javax.servlet.ServletException: java.lang.NullPointerException
   org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:603)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
   org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:374)
   org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
   org.kohsuke.stapler.Stapler.service(Stapler.java:159)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94)
   
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
   hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97)
   hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86)
   hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
   
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
   
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
   hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
   
 hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
 root cause
 java.lang.NullPointerException
   
 org.jenkins.ci.plugins.jobimport.JobImportAction.doImport(JobImportAction.java:126)
   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   java.lang.reflect.Method.invoke(Method.java:616)
   org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
   org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
   
 org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
   org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
   
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
   org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:374)
   org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
   org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
   org.kohsuke.stapler.Stapler.service(Stapler.java:159)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94)
   
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
   hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97)
   hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86)
   hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
   
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
   
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
   hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
   
 hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
 note The full stack trace of the root cause is available in the Apache 
 Tomcat/6.0.33 logs.
 Apache Tomcat/6.0.33

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

[JIRA] (JENKINS-4087) allow hot deployment of new plugins

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


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

jieryn resolved JENKINS-4087.
-

Resolution: Fixed

Fixed in Jenkins 1.440 via 
https://github.com/jenkinsci/jenkins/commit/c6d81ef2e26e55dd3341a6eacd113a1f58023f73

 allow hot deployment of new plugins
 ---

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

 technically it should be possible...
 updates of existing plugins is another matter.

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

[JIRA] (JENKINS-13536) File parameter causing data lost after Jenkins restart

2012-04-20 Thread darkpa...@gmail.com (JIRA)

Blazej Mirowski created JENKINS-13536:
-

 Summary: File parameter causing data lost after Jenkins restart
 Key: JENKINS-13536
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13536
 Project: Jenkins
  Issue Type: Bug
  Components: parameters
Affects Versions: current
 Environment: Debian 2.6.32-5-amd
Reporter: Blazej Mirowski
Priority: Critical
 Attachments: build.xml

Hi,

We have encountered problems when using File parameter in our jobs.

How to reproduce problem:
1) create job
2) mark This build is parametrized
2a) Add Parameter - File Parameter
2b) File location - data.file
2c) description - plik
3) Build
3a) Add build step - Execute shell:
   ls -la
   mv data.file data.zip
   sleep 10
   rm *
4) trigger new job and use big *.zip file as parameter (~150MB)

During file upload on master in /tmp directory new file will be created - for 
example upload_6e074d3b_136c03af218__8000_0013.tmp.
When job finish this *.tmp file usually is deleted automatically - and here our 
problems are starting.
In build.xml additional note is added:
  file class=org.apache.commons.fileupload.disk.DiskFileItem 
serialization=custom
org.apache.commons.fileupload.disk.DiskFileItem
  default
isFormFieldfalse/isFormField
size153052917/size
sizeThreshold10240/sizeThreshold
contentTypeapplication/zip/contentType

dfosFile/tmp/upload_6e074d3b_136c03af218__8000_0013.tmp/dfosFile
fieldNamefile0/fieldName
fileNameWN6.0_MP4.4_22.12.zip/fileName
  /default
/org.apache.commons.fileupload.disk.DiskFileItem
  /file
When we are restarting jenkins it is not able to read this jobs because this 
temporary file do not exists - job history is not visible from Jenkins but 
builds exists on machine. Error message after Jenkins restart:
...
Caused by: com.thoughtworks.xstream.converters.ConversionException: Could not 
call org.apache.commons.fileupload.disk.DiskFileItem.readObject() : 
/tmp/upload_6e074d3b_136c03af218__8000_0013.tmp (No such file or directory)
 Debugging information 
message : Could not call 
org.apache.commons.fileupload.disk.DiskFileItem.readObject()
cause-exception : java.io.FileNotFoundException
cause-message   : /tmp/upload_6e074d3b_136c03af218__8000_0013.tmp (No 
such file or directory)
class   : hudson.model.FreeStyleBuild
required-type   : org.apache.commons.fileupload.disk.DiskFileItem
path: 
/build/actions/hudson.model.ParametersAction/parameters/hudson.model.FileParameterValue/file/org.apache.commons.fileupload.disk.DiskFileItem
line number : 32
---
...

Could you please help to check this?



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

[JIRA] (JENKINS-13441) Slave status information shouldn't be stored in main config file

2012-04-20 Thread jacob.robertson.w...@gmail.com (JIRA)


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

jacob_robertson updated JENKINS-13441:
--

Component/s: (was: configurationslicing)

Configuration slicing does not in any way influence where/how the configuration 
is saved.  Removing that component.

 Slave status information shouldn't be stored in main config file
 

 Key: JENKINS-13441
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13441
 Project: Jenkins
  Issue Type: Improvement
  Components: master-slave, slave-status
Affects Versions: current
Reporter: Andreas Kotes
Assignee: mdonohue

 Jenkins stores slave information as well as their status in the main config 
 file. As we've automated the configuration via Puppet, any automated changes 
 trigger and overwrite and service restart (if not handled properly). Such is 
 the case for slave state changes, e.g. when a slave goes offline due to disk 
 usage issues.
 Suggestion: split of slave configuration (or at least their status 
 information) into a separate configuration file.

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

[JIRA] (JENKINS-10628) SCM build trigger not working correctly with variables in SVN URL


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

Spike Hains commented on JENKINS-10628:
---

We absolutely love the speed, ease of use, and elegance of Jenkins, but not 
being able to use SCM polling for our QA builds is quite an inconvenience. Is 
there a workaround perhaps?

 SCM build trigger not working correctly with variables in SVN URL
 -

 Key: JENKINS-10628
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10628
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
Reporter: creckord
Assignee: sogabe

 I tried using variables in my SVN URL with Subversion plug-in 1.29, but now 
 the SCM build trigger triggers a new build on every update check.
 I created two global variables in the Jenkins System Configuration:
MYSVN_BASE=file:///home/svn/myproject
MYSVN_BRANCH=trunk
 and in my build job I use 

$MYSVN_BASE/$MYSVN_BRANCH 
 as the SVN URL and the SCM build trigger set to check every 15 minutes for 
 updates.
 Despite a nasty Invalid URL syntax error marker below the URL field, 
 checking out and building the project works fine. However, the log says:
 Started by an SCM change
 Updating file:///home/svn/myproject/trunk
 At revision 13360
 no revision recorded for $MYSVN_BASE/$MYSVN_BRANCH in the previous build
 And on any subsequent SCM check, the build is triggered with that same 
 message...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 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=161814#comment-161814
 ] 

Sylvain C. commented on JENKINS-12163:
--

My solution :

* Configure the slave with a disconnect type of Shutdown.
* Create two new jobs :

- SwitchOffLineNode (Change status of a node from Online to Offline)
With a string parameter : name = NODE
With a build step of windows batch type :
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
offlineMessage=back_in_a_momentjson=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7DSubmit=Mark+this+node+temporarily+offline
 %JENKINS_URL%computer/%NODE%/toggleOffline  nul 21{code}
Replace USERNAME  USERPASSWORD
- SwitchOnLineNode (Change status of a node from OffLine to Online)
With a string parameter : name = NODE
With a build step of windows batch type:
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
Submit=This+node+is+back+online %JENKINS_URL%computer/%NODE%/toggleOffline  
nul 21{code}
Replace USERNAME  USERPASSWORD

* Configure your job :
First build step windows batch command:
{code:lang=html}set json={\parameter\: [{\name\:\NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOfflineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%{code}
Replace USERNAME  USERPASSWORD
This build step switch offline the vmware to stop new build

* On Post build task of your job (download post build plugin)
Log Text = Building (to execute this task all the time like a finally)
Script
{code:lang=html}set json={\parameter\: [{\name\: \NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOnlineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%
shutdown -s -f -t 30{code}
Replace USERNAME  USERPASSWORD
This script turns off the vmware and after switches online the vmware to 
execute new job.

I use this solution to run testcomplete (graphic tests) jobs and I must run 
tests from a clean machine.

 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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 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=161814#comment-161814
 ] 

Sylvain C. edited comment on JENKINS-12163 at 4/20/12 1:37 PM:
---

My solution :

* Configure the slave with a disconnect type of Shutdown or nothing.
* Create two new jobs :

- SwitchOffLineNode (Change status of a node from Online to Offline)
With a string parameter : name = NODE
With a build step of windows batch type :
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
offlineMessage=back_in_a_momentjson=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7DSubmit=Mark+this+node+temporarily+offline
 %JENKINS_URL%computer/%NODE%/toggleOffline  nul 21{code}
Replace USERNAME  USERPASSWORD
- SwitchOnLineNode (Change status of a node from OffLine to Online)
With a string parameter : name = NODE
With a build step of windows batch type:
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
Submit=This+node+is+back+online %JENKINS_URL%computer/%NODE%/toggleOffline  
nul 21{code}
Replace USERNAME  USERPASSWORD

* Configure your job :
First build step windows batch command:
{code:lang=html}set json={\parameter\: [{\name\:\NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOfflineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%{code}
Replace USERNAME  USERPASSWORD
This build step switch offline the vmware to stop new build

* On Post build task of your job (download post build plugin)
Log Text = Building (to execute this task all the time like a finally)
Script
{code:lang=html}set json={\parameter\: [{\name\: \NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOnlineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%
shutdown -s -f -t 30{code}
Replace USERNAME  USERPASSWORD
This script turns off the vmware and after switches online the vmware to 
execute new job.

I use this solution to run testcomplete (graphic tests) jobs and I must run 
tests from a clean machine.

  was (Author: sylvainc):
My solution :

* Configure the slave with a disconnect type of Shutdown.
* Create two new jobs :

- SwitchOffLineNode (Change status of a node from Online to Offline)
With a string parameter : name = NODE
With a build step of windows batch type :
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
offlineMessage=back_in_a_momentjson=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7DSubmit=Mark+this+node+temporarily+offline
 %JENKINS_URL%computer/%NODE%/toggleOffline  nul 21{code}
Replace USERNAME  USERPASSWORD
- SwitchOnLineNode (Change status of a node from OffLine to Online)
With a string parameter : name = NODE
With a build step of windows batch type:
{code:lang=html}cd %CURL_HOME%  curl \-k \-u USERNAME:USERPASSWORD \-d 
Submit=This+node+is+back+online %JENKINS_URL%computer/%NODE%/toggleOffline  
nul 21{code}
Replace USERNAME  USERPASSWORD

* Configure your job :
First build step windows batch command:
{code:lang=html}set json={\parameter\: [{\name\:\NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOfflineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%{code}
Replace USERNAME  USERPASSWORD
This build step switch offline the vmware to stop new build

* On Post build task of your job (download post build plugin)
Log Text = Building (to execute this task all the time like a finally)
Script
{code:lang=html}set json={\parameter\: [{\name\: \NODE\, \value\: 
\%NODE_NAME%\}], \\: \\}
set url=%JENKINS_URL%/job/SwitchOnlineNode/build?delay=60sec
cd %CURL_HOME%  curl -k -u USERNAME:USERPASSWORD -X POST %url% 
--data-urlencode json=%json%
shutdown -s -f -t 30{code}
Replace USERNAME  USERPASSWORD
This script turns off the vmware and after switches online the vmware to 
execute new job.

I use this solution to run testcomplete (graphic tests) jobs and I must run 
tests from a clean machine.
  
 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

[JIRA] (JENKINS-9478) NullPointerException while submitting config slicer logrotationbuilds or logrotationdays

2012-04-20 Thread ever...@free.fr (JIRA)


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

evernat commented on JENKINS-9478:
--

@batmat
I do not see the log which is supposed to be attached.
Do you have the log or is this issue obsolete?

 NullPointerException while submitting config slicer logrotationbuilds or 
 logrotationdays
 

 Key: JENKINS-9478
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9478
 Project: Jenkins
  Issue Type: Bug
 Environment: AIX JDK, Glassfish v2.1, Jenkins 1.408
Reporter: batmat
Assignee: mdonohue

 Trying to update the logrotations* values, it ends up with a NPE.
 I'm attaching the log, after calling successively called both.
 Cheers

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 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) When a job restricted to only one label is launched, the plugin performs a revert snapshot of all the vmwares that have this label

Sylvain C. created JENKINS-13537:


 Summary: When a job restricted to only one label is launched, the 
plugin performs a revert snapshot of all the vmwares that have this label
 Key: JENKINS-13537
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13537
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
Reporter: Sylvain C.


I have 3 identical vmwares with the same label but when I run a job restricted 
to this label Vsphere plugin makes a revert snapshot action on all vmwares 
which 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
 ]

Sylvain C. updated JENKINS-13537:
-

  Summary: Not perform revert snapshot for all vmwares of a label 
 (was: When a job restricted to only one label is launched, the plugin performs 
a revert snapshot of all the vmwares that have this label)
Affects Version/s: current
  Description: When a job restricted to only one label is launched, the 
plugin performs a revert snapshot of all the vmwares that have this label  
(was: I have 3 identical vmwares with the same label but when I run a job 
restricted to this label Vsphere plugin makes a revert snapshot action on all 
vmwares which have this label.)

 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.

 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-12311) Display the Deployed Artifacts in a tree structure similar to how they are displayed under the Build Artifacts section

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

bogdaniosif reopened JENKINS-12311:
---

Please make this behaviour optional. I can't use this plugin past v0.15 because
of this change.

My arguments:
- Full paths on the build server are now visible to web ui users, which is I
find undesirable
- When a user wishes to save an artifact locally, the name generated by the
browser for the file to be downloaded is unusable as it is actually the full
path of the file on the build server, meshed together by removing path
separators

For me, the behavior pre 0.16 was ideal because I'm archiving a couple of
zipped packages per build which actually have by design unique names and it
makes perfect sense to have them in a flat view.

Please make this behavior optional. I was very thankful to have found this
plugin at v0.7 and I find this change terrible.

Please see screenshots. They tell a good story of just how unusable things have
suddenly become.

Display the Deployed Artifacts in a tree structure similar to how they are
displayed under the Build Artifacts section
--

Key: JENKINS-12311
URL: https://issues.jenkins-ci.org/browse/JENKINS-12311
Project: Jenkins
Issue Type: Improvement
Components: artifactdeployer
Affects Versions: current
Reporter: Chris Williams
Assignee: gbois
Priority: Minor
Attachments: artifact-deployer-plugin.jpg

Currently the deployed artifacts are always presented in a flattened format
on the Jenkins job/build page. Additionally, if there are multiple artifacts
with the same name, but in different directories, the Deployed Artifacts
section will only display one file, with no indication which version of the
file it is. (see attached screenshot)
I'd like to see the Deployed Artifacts displayed in a directory-tree
structure (similar to the normal Build Artifacts section).
Thanks.

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

[JIRA] (JENKINS-12311) Display the Deployed Artifacts in a tree structure similar to how they are displayed under the Build Artifacts section


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

bogdaniosif updated JENKINS-12311:
--

Attachment: Pre 0.16 behavior.jpg

See my comment in the comments section

 Display the Deployed Artifacts in a tree structure similar to how they are 
 displayed under the Build Artifacts section
 --

 Key: JENKINS-12311
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12311
 Project: Jenkins
  Issue Type: Improvement
  Components: artifactdeployer
Affects Versions: current
Reporter: Chris Williams
Assignee: gbois
Priority: Minor
 Attachments: artifact-deployer-plugin.jpg, Post 0.15 behavior.jpg, 
 Pre 0.16 behavior.jpg


 Currently the deployed artifacts are always presented in a flattened format 
 on the Jenkins job/build page. Additionally, if there are multiple artifacts 
 with the same name, but in different directories, the Deployed Artifacts 
 section will only display one file, with no indication which version of the 
 file it is. (see attached screenshot)
 I'd like to see the Deployed Artifacts displayed in a directory-tree 
 structure (similar to the normal Build Artifacts section). 
 Thanks.

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

[JIRA] (JENKINS-12311) Display the Deployed Artifacts in a tree structure similar to how they are displayed under the Build Artifacts section


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

bogdaniosif updated JENKINS-12311:
--

Attachment: Post 0.15 behavior.jpg

See my comment in the comments section

 Display the Deployed Artifacts in a tree structure similar to how they are 
 displayed under the Build Artifacts section
 --

 Key: JENKINS-12311
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12311
 Project: Jenkins
  Issue Type: Improvement
  Components: artifactdeployer
Affects Versions: current
Reporter: Chris Williams
Assignee: gbois
Priority: Minor
 Attachments: artifact-deployer-plugin.jpg, Post 0.15 behavior.jpg, 
 Pre 0.16 behavior.jpg


 Currently the deployed artifacts are always presented in a flattened format 
 on the Jenkins job/build page. Additionally, if there are multiple artifacts 
 with the same name, but in different directories, the Deployed Artifacts 
 section will only display one file, with no indication which version of the 
 file it is. (see attached screenshot)
 I'd like to see the Deployed Artifacts displayed in a directory-tree 
 structure (similar to the normal Build Artifacts section). 
 Thanks.

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

[JIRA] (JENKINS-12311) Display the Deployed Artifacts in a tree structure similar to how they are displayed under the Build Artifacts section

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

bogdaniosif edited comment on JENKINS-12311 at 4/20/12 2:20 PM:

Please make this behaviour optional. I can't use this plugin past v0.15 because
of this change.

My arguments:
- Full paths on the build server are now visible to web ui users, which is
highly undesirable
- When a user wishes to save an artifact locally, the name generated by the
browser for the file to be downloaded is unusable as it is actually the full
path of the file on the build server, meshed together by removing path
separators

For me, the behavior pre 0.16 was ideal because I'm archiving a couple of
zipped packages per build which actually have by design unique names and it
makes perfect sense to have them in a flat view.

Please make this behavior optional. I was very thankful to have found this
plugin at v0.7 and I find this change terrible. Please see the attached
screenshots.

was (Author: bogdaniosif):
Please make this behaviour optional. I can't use this plugin past v0.15
because of this change.

For me, the behavior pre 0.16 was ideal because I'm archiving a couple of
zipped packages per build which actually have by design unique names and it
makes perfect sense to have them in a flat view.

Please make this behavior optional. I was very thankful to have found this
plugin at v0.7 and I find this change terrible.

Please see screenshots. They tell a good story of just how unusable things have
suddenly become.

Display the Deployed Artifacts in a tree structure similar to how they are
displayed under the Build Artifacts section
--

[JIRA] (JENKINS-13538) Build hangs at SVN update occasionally

2012-04-20 Thread jbuer...@arcor.de (JIRA)

J B created JENKINS-13538:
-

 Summary: Build hangs at SVN update occasionally
 Key: JENKINS-13538
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13538
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
 Environment: Ubuntu Linux 11.04 x86
Reporter: J B


Sometimes, when doing a build, it starts to hang at the SVN update. Clicking 
the abort-button does not have any effect, the build processor doing the build 
is thus blocked.
Only restarting Jenkins helps then.
We are doing the SVN update via a external script as a workaround, which isn't 
really convenient.

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

[JIRA] (JENKINS-13039) Max # of builds to keep not deleting old builds

2012-04-20 Thread yve...@gmail.com (JIRA)


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

Yves DM commented on JENKINS-13039:
---

Encountering same issue. 
Using version 1.459 of jenkins on windows 2008 r2 plateform.

 Max # of builds to keep not deleting old builds
 ---

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

 Setting the Max # of builds to keep for a job does not cause old builds to 
 be discarded. I set this as Major as this will lead to the build system dying 
 after running out of disk space.
 I have found a work around here: 
 http://groups.google.com/group/jenkinsci-users/browse_thread/thread/5573bee99bc2c42d
 I created a job in my Jenkins instance to run the following groovy script (as 
 a system groovy script - not sure if that matters...) - this forces the old 
 builds to be discarded per what I have defined in the config:
 {code}
 import hudson.model.*
 for(job in Hudson.instance.items) {
job.logRotate()
 }
 {code}

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

[JIRA] (JENKINS-13499) CertPathValidatorException when trying to use the update center

2012-04-20 Thread jean.he...@gmail.com (JIRA)


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

Jean Helou closed JENKINS-13499.


Assignee: (was: Kohsuke Kawaguchi)

Works for me, thanks!

 CertPathValidatorException when trying to use the update center
 ---

 Key: JENKINS-13499
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13499
 Project: Jenkins
  Issue Type: Bug
  Components: update-center
Reporter: Jean Helou
Priority: Blocker

 On a new install, when trying to use the update center I get this in the logs 
 an no plugins are displayed in the update or install tabs.changing the system 
 date to 2012/04/17 allows me to see the plugins installation of plugins works 
 fine even after setting the system date back to normal
 18 avr. 2012 15:34:51 hudson.model.UpdateSite doPostBack
 GRAVE: div class=errorimg src='/static/6d2d4a0f/images/none.gif' height=16 
 width=1Signature verification failed in the update center 
 #039;default#039; a href='#' class='showDetails'(show details)/apre 
 style='display:none'java.security.cert.CertPathValidatorException: timestamp 
 check failed
   at 
 sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown 
 Source)
   at 
 sun.security.provider.certpath.PKIXCertPathValidator.doValidate(Unknown 
 Source)
   at 
 sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown 
 Source)
   at java.security.cert.CertPathValidator.validate(Unknown Source)
   at 
 org.jvnet.hudson.crypto.CertificateUtil.validatePath(CertificateUtil.java:93)
   at hudson.model.UpdateSite.verifySignature(UpdateSite.java:229)
   at hudson.model.UpdateSite.doPostBack(UpdateSite.java:164)
   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:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
   at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
   at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
   at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
   at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
   at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
   at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
   at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
   at 
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
   at 
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
   at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
   at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
   at 
 hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
   at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
   at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
   at

[JIRA] (JENKINS-13535) GitHub Commits with JIRA case ids surrounded by square brackets don't get links in Changes section

2012-04-20 Thread s.sog...@gmail.com (JIRA)

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

sogabe updated JENKINS-13535:
-

Component/s: jira
(was: github)

Which version of JIRA plugin do you use?
GitHub plugin 1.2, JIRA Plugin 1.29 work fine.

GitHub Commits with JIRA case ids surrounded by square brackets don't get
links in Changes section

Key: JENKINS-13535
URL: https://issues.jenkins-ci.org/browse/JENKINS-13535
Project: Jenkins
Issue Type: Bug
Components: jira
Affects Versions: current
Environment: Jenkins ver. 1.447.2-SNAPSHOT (private-04/12/2012 09:04
GMT-vjuranek). I don't have access to the actual machines running Jenkins,
but since this is actually Red Hat internal QA. It is safe to assume that it
is running on Red Hat Enterprise Linux a.k.a. RHEL.
Reporter: Francisco Borges
Priority: Minor
Attachments: NoChangesLinksWithLeadingSquareBracket.png

I am a Red Hat HornetQ developer https://github.com/hornetq/hornetq some team
members write commits messages like this
[JIRA-1234] Fixed something.
Turns out that JIRA case id surrounded by square brackets will make the
commit to have no links nor commit description in the Changes section.
FWIW, one actual such commit message is
[HORNETQ-906] fix broken tests taken from
https://github.com/hornetq/hornetq/commit/a4017b203ec097ec4fd2af9c27c3bad35426e667

See the attached screen shot for what happens with our Changes view.

[JIRA] (JENKINS-13531) Plugin replacing + with in configuration strings when plugin is instantiated.

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

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

glimberg updated JENKINS-13531:
---

Summary: Plugin replacing + with in configuration strings when plugin
is instantiated. (was: Plugin form field replacing + with )

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

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

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

[JIRA] (JENKINS-11937) Excluded regions only work for one check-in after a build

2012-04-20 Thread westhus...@gmail.com (JIRA)

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

Adam Westhusing resolved JENKINS-11937.
---

Fix Version/s: current
Resolution: Cannot Reproduce

I think the issue with this was commits that are merges. The merges don't show
up in Jenkins, but in the repository they contain changes that referred to
projects not in the ignored list.

Resolving as 'Cannot Reproduce'

Excluded regions only work for one check-in after a build
-

Key: JENKINS-11937
URL: https://issues.jenkins-ci.org/browse/JENKINS-11937
Project: Jenkins
Issue Type: Bug
Components: git
Affects Versions: current
Environment: Windows 7 64-bit, Git Plugin 1.1.13
Reporter: Adam Westhusing
Assignee: abayer
Labels: plugin
Fix For: current

For our build environment, I am using the Git plugin (1.1.13) with Jenkins.
In order to do incremental builds to cut down on total build time, I am using
the excluded regions feature of the plugin. This feature appears to work,
but only after one check-in.
Here's my example:
Check-in for project A.
Project A builds.
Check-in for project B.
Project B builds (Project A correctly ignores the check-in for project B).
Check-in for project B.
Project A and B build (Project A does not ignore the check-in for project B
when there are multiple check-ins to ignore).
This issue appears to be similar to JENKINS-8342, however it does not appear
to be dependent on the quiet period. This issue will happen 100% of the time
in my environment when trying to ignore a 2nd check-in. I don't know after
that point because the ignore list presumably gets reset after a build.
This issue affects plugin version 1.1.12 and 1.1.13 in my testing.

[JIRA] (JENKINS-13051) Setting branch name prevents branch from building

2012-04-20 Thread westhus...@gmail.com (JIRA)


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

Adam Westhusing commented on JENKINS-13051:
---

I was able to work around this issue with the latest plugin (1.1.17) by using 
the branch name as **/master.  However, this only works if you are only working 
with one repository.

 Setting branch name prevents branch from building
 -

 Key: JENKINS-13051
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13051
 Project: Jenkins
  Issue Type: Bug
  Components: git
 Environment: Windows Server 2008 R2, Jenkins 1.454, Git Plugin 
 1.1.16, Git version 1.7.9-preview20120201
Reporter: Adam Westhusing
Assignee: Nicolas De Loof
Priority: Critical
  Labels: git, plugin, windows

 It appears a bug has been introduced in Git plugin 1.1.16:
 If I set the branch specifier in the Branches to Build section, I always 
 get the following error.
 ERROR: Couldn't find any revision to build. Verify the repository and branch 
 configuration for this job.
 The only way I found to resolve this is to get rid of the branch specifier 
 and replace it with **.  However, I only want to build a specific branch in 
 our Git repo, so in the meantime I've rolled back to 1.1.15 where this 
 functionality is working just fine.

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

[JIRA] (JENKINS-13051) Setting branch name prevents branch from building

2012-04-20 Thread westhus...@gmail.com (JIRA)

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

Adam Westhusing edited comment on JENKINS-13051 at 4/20/12 6:39 PM:

I was able to work around this issue with the latest plugin (1.1.17) by using
the branch name as **/master. However, this only works if you are only working
with one repository. Setting the branch name as origin/master fails, even
though the Git polling log calls the branch origin/master.

was (Author: westhusing):
I was able to work around this issue with the latest plugin (1.1.17) by
using the branch name as **/master. However, this only works if you are only
working with one repository.

Setting branch name prevents branch from building
-

Key: JENKINS-13051
URL: https://issues.jenkins-ci.org/browse/JENKINS-13051
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows Server 2008 R2, Jenkins 1.454, Git Plugin
1.1.16, Git version 1.7.9-preview20120201
Reporter: Adam Westhusing
Assignee: Nicolas De Loof
Priority: Critical
Labels: git, plugin, windows

It appears a bug has been introduced in Git plugin 1.1.16:
If I set the branch specifier in the Branches to Build section, I always
get the following error.
ERROR: Couldn't find any revision to build. Verify the repository and branch
configuration for this job.
The only way I found to resolve this is to get rid of the branch specifier
and replace it with **. However, I only want to build a specific branch in
our Git repo, so in the meantime I've rolled back to 1.1.15 where this
functionality is working just fine.

[JIRA] (JENKINS-13539) Failed to parse form data. Please report this problem as a bug

2012-04-20 Thread doug...@hotmail.com (JIRA)

dou ngo created JENKINS-13539:
-

 Summary: Failed to parse form data. Please report this problem as 
a bug
 Key: JENKINS-13539
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13539
 Project: Jenkins
  Issue Type: Bug
  Components: all-changes
Affects Versions: current
 Environment: Mac Lion
Reporter: dou ngo
Assignee: wolfs



Skip to content

 
php-template
Error

Failed to parse form data. Please report this problem as a bug
JSON={:embed height=\300\ src=\ws/build/pdepend/overview-pyramid.svg\ 
type=\image/svg+xml\ width=\500\\/embed\nembed height=\300\ 
src=\ws/build/pdepend/dependencies.svg\ type=\image/svg+xml\ 
width=\500\\/embed,builder:{antOpts:,buildFile:/Users/dougngo/dev/FCE/build.xml,kind:hudson.tasks.Ant,properties:,stapler-class:hudson.tasks.Ant,targets:},core:apply:,description:embed
 height=\300\ src=\ws/build/pdepend/overview-pyramid.svg\ 
type=\image/svg+xml\ width=\500\\/embed\nembed height=\300\ 
src=\ws/build/pdepend/dependencies.svg\ type=\image/svg+xml\ 
width=\500\\/embed,displayNameOrNull:,htmlpublisher-HtmlPublisher:{reportTargets:[{keepAll:false,reportDir:build/api,reportFiles:index.html,reportName:API
 
Documentation},{keepAll:false,reportDir:build/code-browser,reportFiles:index.html,reportName:Code
 
Browser}]},hudson-plugins-checkstyle-CheckStylePublisher:{canComputeNew:{failedNewAll:,failedNewHigh:,failedNewLow:,failedNewNormal:,unstableNewAll:,unstableNewHigh:,unstableNewLow:,unstableNewNormal:,useDeltaValues:false},canRunOnFailed:true,defaultEncoding:,failedTotalAll:,failedTotalHigh:,failedTotalLow:,failedTotalNormal:,healthy:,pattern:build/logs/checkstyle.xml,shouldDetectModules:false,thresholdLimit:low,unHealthy:,unstableTotalAll:,unstableTotalHigh:,unstableTotalLow:,unstableTotalNormal:},hudson-plugins-dry-DryPublisher:{canComputeNew:{failedNewAll:,failedNewHigh:,failedNewLow:,failedNewNormal:,unstableNewAll:,unstableNewHigh:,unstableNewLow:,unstableNewNormal:,useDeltaValues:false},canRunOnFailed:true,defaultEncoding:,failedTotalAll:,failedTotalHigh:,failedTotalLow:,failedTotalNormal:,healthy:,highThreshold:50,normalThreshold:25,pattern:build/logs/pmd-cpd.xml,shouldDetectModules:false,thresholdLimit:low,unHealthy:,unstableTotalAll:,unstableTotalHigh:,unstableTotalLow:,unstableTotalNormal:},hudson-plugins-jdepend-JDependRecorder:{configuredJDependFile:build/logs/jdepend.xml},hudson-plugins-plot-PlotPublisher:{plots:[{csvFileName:123.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:A
 - Lines of code,useDescr:false,yaxis:Lines of 
Code},{csvFileName:1107599928.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:B
 - 
Structures,useDescr:false,yaxis:Count},{csvFileName:523405415.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:G
 - Average Length,useDescr:false,yaxis:Average Non-Comment Lines of 
Code},{csvFileName:186376189.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:H
 - Relative Cyclomatic Complexity,useDescr:false,yaxis:Cyclomatic 
Complexity by 
Structure},{csvFileName:594356163.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:D
 - Types of 
Classes,useDescr:false,yaxis:Count},{csvFileName:1019987862.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:E
 - Types of 
Methods,useDescr:false,yaxis:Count},{csvFileName:217648577.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv},style:line,title:F
 - Types of 
Constants,useDescr:false,yaxis:Count},{csvFileName:174807245.csv,group:phploc,numBuilds:100,series:{file:build/logs/phploc.csv,fileType:{displayTableFlag:false,exclusionValues:Classes,Methods,Functions,Test
 Clases,Test 
Methods,inclusionFlag:INCLUDE_BY_STRING,url:,value:csv}},style:line,title:C
 -

[JIRA] (JENKINS-11673) Support https in RPM service scripts

2012-04-20 Thread te...@java.net (JIRA)


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

teilo commented on JENKINS-11673:
-

add an option HTTPS_PORT

If set then enable the http port.
otherwise you can't do it without knowing the parameters that you need to pass 
to the jar.

Fix is done - just need to get the file so I can push it.

 Support https in RPM service scripts
 

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

 It would be nice if the RPM allowed you to simply configure https as well as 
 http

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

[JIRA] (JENKINS-11673) Support https in RPM service scripts

2012-04-20 Thread y...@shurup.com (JIRA)


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

Work on JENKINS-11673 started by teilo.

 Support https in RPM service scripts
 

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

 It would be nice if the RPM allowed you to simply configure https as well as 
 http

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

[JIRA] (JENKINS-12382) Typo with displayed text for cppcheck plugin configuration in Jenkins

2012-04-20 Thread gb...@java.net (JIRA)


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

gbois resolved JENKINS-12382.
-

Resolution: Fixed

 Typo with displayed text for cppcheck plugin configuration in Jenkins
 -

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

 The cppcheck plugin in Jenkins displays the following text for for severity 
 reporting configuration:
 Configure the build status and health. A build is considered as unstable or 
 failure if the new or total number of errors exceeds the specified 
 thresholds. The build health is also determined by thresholds. If the actual 
 number of errors is between the provided thresholds, then the build health is 
 interpolated.
 severiry.evaluationSeverity 'error'  Severity 'warning'  Severity 'style' 
  Severity 'performance'  Severity 'information' 
 severiry.evaluation should be severity.evaluation

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

[JIRA] (JENKINS-5625) Honor the Default user e-mail suffix setting in E-Mail recipients field

2012-04-20 Thread n...@nngo.net (JIRA)


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

Neon Ngo commented on JENKINS-5625:
---

If the Default user e-mail suffix field is NOT fixed, then it should probably 
be DISABLED until it is fixed or REMOVED to prevent confusion.

 Honor the Default user e-mail suffix setting in E-Mail recipients field
 -

 Key: JENKINS-5625
 URL: https://issues.jenkins-ci.org/browse/JENKINS-5625
 Project: Jenkins
  Issue Type: Improvement
  Components: mail
Affects Versions: current
Reporter: mjparme
Priority: Minor

 There is a setting called Default user e-mail suffix under Manage 
 Hudson-Configure System that allows you to set a default suffix to append to 
 the end of email addresses, for example if you set it as @example.com and 
 then in your projects you set email recipient to be foo it used to send the 
 email to f...@example.com. This setting is no longer honored and now the 
 attempt to send the email is sent to just foo which of course fails.
 I am unsure which version this started to fail in but it has been within the 
 last few releases. It affects the current 1.345 and also affected 1.344 for 
 sure.

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

[JIRA] (JENKINS-8381) Robot summary and trend graph for multi-configuration project

2012-04-20 Thread mcroo...@java.net (JIRA)


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

mcrooney commented on JENKINS-8381:
---

This would be awesome for sure. We use the RF plugin in a multi-configuration 
project to run across multiple browsers in parallel, and an aggregated view at 
the parent project level would be great.

jpiironen, if you are interested in being a mentor I'm happy to attempt this, 
as I've written and contributed to a few plugins.

 Robot summary and trend graph for multi-configuration project
 -

 Key: JENKINS-8381
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8381
 Project: Jenkins
  Issue Type: New Feature
  Components: robot-plugin
Reporter: jpiironen
Assignee: jpiironen

 As a user I want to see aggregated results of component builds on 
 multi-configuration project's project page so that I can verify the state of 
 my builds with a glance.
 -Individual graphs for every configuration on project page (all tests 
 aggregated wouldn't be too informative)
 -Configuration's pages should have the normal Robot components of a project 
 page
 -Remove link from sidebar if useless

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

[JIRA] (JENKINS-12504) cppcheck-plugin doesn't display the latest source when cppcheck-plugin is the cause of a build failure

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

SCM/JIRA link daemon commented on JENKINS-12504:

Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckProjectAction.java
http://jenkins-ci.org/commit/cppcheck-plugin/7a5165bcdcbd212e3a6d48d98a5e13a9929c0aab
Log:
Fix JENKINS-12504

cppcheck-plugin doesn't display the latest source when cppcheck-plugin is the
cause of a build failure
--

Key: JENKINS-12504
URL: https://issues.jenkins-ci.org/browse/JENKINS-12504
Project: Jenkins
Issue Type: Bug
Components: cppcheck
Affects Versions: current
Environment: CentOS 5.7 Jenkins 1.434
Reporter: Chris Welch
Assignee: gbois

The cppcheck plugin has a very confusing behaviour when it is configured to
fail builds.
Set up a project such that the project builds fine on its own, but has a
cppcheck error in it.
Configure the cppcheck-plugin threshold level to fail the build if there are
more then 0 cppcheck error issues found.
Run the build.
Click on the cppcheck link.
You'll get the message This plugin will not report cppcheck result until
there is at least one success or unstable build.
You are prevented from seeing the cppcheck results which caused the failed
build!
This gets even more confusing when there have been successful builds in the
past. The results that are displayed are for the last successful build, even
though the cppcheck plugin is the source of the build failure. This makes
the build look like the latest changes haven't been picked up because the old
source code is displayed.
Overall, this behaviour prevents you from seeing the source of the build
failure, which is the latest cppcheck-plugin results. This makes it quite
challenging to fix the source of the build failure because you can't see it
from the the latest cppcheck build results. You have to drill into the
specific build, then look at the cppcheck results.
The plugin needs to see if the build failure was because of a build step, or
if the cppcheck plugin failed the build because of a cppcheck-plugin
threshold being exceeded.
If the build failure is a result of the cppcheck-plugin threshold being
exceeded, the cppcheck-plugin should show the latest cppcheck results so that
the cppcheck failure can be investigated and corrected.

[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows

2012-04-20 Thread nicholas.floyd.i...@gmail.com (JIRA)


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

Nick Floyd commented on JENKINS-13417:
--

Confirmed that this is an issue in git plugin v1.1.17; like @djs we reverted 
back to 1.1.15.

 git-plugin: rev-parse dereferencing tags breaks on Windows
 --

 Key: JENKINS-13417
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
 Project: Jenkins
  Issue Type: Bug
  Components: git
 Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin 
 git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof

 The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0 
 seems to break the git plugin for Windows, at least in some circumstances.  
 The syntax rev^{commit} gets mangled by cmd because ^ is a quote character.  
 This means that cmd passes rev{commit} to git, which as a cygwin executable 
 being run from Windows, further tries to do wildcard expansion and maps this 
 to revcommit.  Putting  around rev^{commit} empirically seems to work, 
 though I haven't tried it in the git plugin itself.
 This C fragment:
 {code}
 #include stdio.h
 int main(int argc, char* argv[])
 {
 int i;
 for (i = 0; i  argc; ++i)
 {
 printf(%s\n, argv[i]);
 }
 return 0;
 }
 {code}
 when compiled with mingw to a native Windows application (a.exe) and invoked 
 from cmd as a.exe a^{b} prints a{b}.  When the same fragment is compiled with 
 cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd, 
 it prints ab.  Both print a^{b} when invoked from cmd as a.exe a^{b}.
 I'm not sure what the fix is here other than perhaps detecting that this is 
 windows and putting quotes around the argument in Windows.
 On another note, I left the Affects Version/s field blank.  My Jenkins 
 installation claims that it is using version 1.1.6.  Looking at the git repo 
 for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet 
 running strings on 
 plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class clearly shows 
 that my git plugin has that change in 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-13540) Redirects do not work properly on IE

2012-04-20 Thread jdmarsh...@gmail.com (JIRA)

Jason Marshall created JENKINS-13540:


 Summary: Redirects do not work properly on IE
 Key: JENKINS-13540
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13540
 Project: Jenkins
  Issue Type: Bug
  Components: other
Affects Versions: current
 Environment: Internet Explorer
Reporter: Jason Marshall


TL;DR:  Make the 404 redirect page longer so IE behaves, or change how 
redirects work.


Let's say you have a build with no test reports (eg, a cancelled build).  Try 
to enter the testReport page:

http://jenkins:8080/job/MyProject/1325/testReport/

Jenkins will perform a 302 Found redirect to 

http://jenkins:8080/job/MyProject/1325/testReport/?

This will load a 404 page with the following contents:

htmlheadmeta http-equiv='refresh' 
content='1;url=..'/scriptwindow.location.replace('..');/script/headbody 
style='background-color:white; color:white;'Not found/body/html

On Chrome and Firefox this will redirect to 
http://jenkins:8080/job/MyProject/1325 which is probably what you expected.  IE 
will not.  It will instead redirect to its own internal 404 page.

I think this page purports to tell why this happens.  It says that the page 
needs to be 512 bytes or it's ignored:

http://www.404-error-page.com/404-error-page-too-short-problem-microsoft-ie.shtml

The upshot is that it would be good if either both redirects used a 302 Found, 
or perhaps a simpler solution would be if the 404 meta-redirect had more 
content so that Explorer took it seriously.




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

[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes

2012-04-20 Thread guillaume.bilod...@gmail.com (JIRA)


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

Guillaume Bilodeau updated JENKINS-13227:
-

Priority: Critical  (was: Major)

 CVS plugin 2.1 does not detect changes
 --

 Key: JENKINS-13227
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
Reporter: Guillaume Bilodeau
Priority: Critical
  Labels: cvs

 As presented in the user group: 
 https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4
 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS 
 repository for a few weeks now, without any problems. The CVS plugin (v1.6) 
 was using the local cvsnt install.
 We've since upgraded the CVS plugin to version 2.1 (by manually pinning the 
 plugin) and since then, CVS changes are not detected. The CVS polling log is 
 triggered properly, tons of cvs rlog instructions are sent, but at the end 
 No changes is displayed.
 Using CVS plugin 1.6 the cvs polling command looked like this (executed at 
 5:26:21 PM EDT):
 cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 
 Thursday, March 22, 2012 9:26:21 PM UTC
 Using CVS plugin 2.1, the last cvs checkout command looked like this 
 (executed at 11:56:16 AM EDT):
 cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 
 11:56:16 EDT -d portailInt portailInt
 We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect.

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

[JIRA] (JENKINS-13524) Validate project naming regex immediately

2012-04-20 Thread s.sog...@gmail.com (JIRA)


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

sogabe reassigned JENKINS-13524:


Assignee: sogabe

 Validate project naming regex immediately
 -

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

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

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

[JIRA] (JENKINS-13524) Validate project naming regex immediately


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

SCM/JIRA link daemon commented on JENKINS-13524:


Code changed in jenkins
User: Seiji Sogabe
Path:
 changelog.html
 core/src/main/java/jenkins/model/ProjectNamingStrategy.java
 core/src/main/resources/jenkins/model/Messages.properties
 core/src/main/resources/jenkins/model/Messages_ja.properties
 
core/src/main/resources/jenkins/model/ProjectNamingStrategy/PatternProjectNamingStrategy/config.groovy
http://jenkins-ci.org/commit/jenkins/5587d13f58b14bffa9f77f7433358e14add9bcfa
Log:
  [FIXED JENKINS-13524] Validate project naming regex immediately






 Validate project naming regex immediately
 -

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

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

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

[JIRA] (JENKINS-13524) Validate project naming regex immediately