[JIRA] (JENKINS-13131) SSH may stale for 15 minutes after slave restart

2012-03-18 Thread g...@rzn.co.il (JIRA) 
Guy Rozendorn created JENKINS-13131:
---

 Summary: SSH may stale for 15 minutes after slave restart
 Key: JENKINS-13131
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13131
 Project: Jenkins
  Issue Type: Bug
  Components: ssh-slaves
Affects Versions: current
Reporter: Guy Rozendorn
Assignee: Kohsuke Kawaguchi
Priority: Critical


We often reboot our slaves. Most of the time they reconnect quickly, but every 
one of ten slaves just does not reconnect -- in the slave log page we see the 
circle turning and without any test. After 15-20 minutes it begins to work. 
While we wait for this to work, we can manually ssh to the server without any 
problem.

--
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-4950) NPE when trying to remove a dead node

2012-03-18 Thread baskaran...@gmail.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160389#comment-160389
 ] 

Baskaran D commented on JENKINS-4950:
-

Is there any way to remove these dead nodes directly through any configuration 
files?


> NPE when trying to remove a dead node
> -
>
> Key: JENKINS-4950
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4950
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: vessel
>Priority: Critical
>
> Hi,
> I currently have a node in the farm that has the Status "Dead(!)".
> Clicking on this "Dead(!)" shows:  Thread is still alive.
> And trying to delete the node from the farm gives me a NPE:
> java.lang.NullPointerException
>   at hudson.model.Hudson.removeNode(Hudson.java:1411)
>   at hudson.model.Computer.doDoDelete(Computer.java:915)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:185)
>   at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:101)
>   at 
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:54)
>   at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:74)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:489)
>   at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:318)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:489)
>   at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:144)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:489)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:405)
>   at org.kohsuke.stapler.Stapler.service(Stapler.java:116)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
>   at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
>   at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
>   at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94)
>   at
> org.jvnet.hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:38)
>   at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97)
>   at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86)
>   at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>   at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
>   at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
>   at
> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
>   at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>   at
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
>   at
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegr

[JIRA] (JENKINS-4744) Can't delete dead ec2-generated nodes

2012-03-18 Thread baskaran...@gmail.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160388#comment-160388
 ] 

Baskaran D commented on JENKINS-4744:
-

Is there any way to remove these dead nodes directly through any configuration 
files?

> Can't delete dead ec2-generated nodes
> -
>
> Key: JENKINS-4744
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4744
> Project: Jenkins
>  Issue Type: Bug
>  Components: ec2
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: pjimenez3
>Assignee: francis Upton
>Priority: Critical
>
> If you manually kill an EC2 instance that hudson was using, it gets stuck.  
> Trying to delete the node in hudson results in:
> ava.lang.NullPointerException
>   at hudson.plugins.ec2.EC2Computer.doDoDelete(EC2Computer.java:92)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
> a:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:185)
>   at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:101)
>   at 
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:54)
>   at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:74)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487)
>   at org.kohsuke.stapler.MetaClass$8.dispatch(MetaClass.java:215)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487)
>   at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:144)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:403)
>   at org.kohsuke.stapler.Stapler.service(Stapler.java:116)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
>   at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
>   at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
>   at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94)
>   at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86)
>   at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>   at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
>   at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>   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:195)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>   at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
>   at 
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
>   at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
>   at java.lang.Thread.run(Thread.java:595)

--
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-13130) Gradle Plugin - Gradle distribution URL has changed

2012-03-18 Thread gcon...@internode.on.net (JIRA) 
Glen Conboy created JENKINS-13130:
-

 Summary: Gradle Plugin - Gradle distribution URL has changed
 Key: JENKINS-13130
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13130
 Project: Jenkins
  Issue Type: Task
  Components: gradle
Affects Versions: current
Reporter: Glen Conboy
Assignee: gbois
Priority: Minor


The lastest Gradle distribution (1.0 milestone 9) cannot be selected in the 
"Install from Gradle.org" drop down list.
 
I would guess that this is because the Gradle distrubition URL has changed from 
http://repo.gradle.org/gradle/distributions to 
http://services.gradle.org/distributions . See the Gradle release note 
http://wiki.gradle.org/display/GRADLE/Gradle+1.0-milestone-8+Migration+Guide#Gradle1.0-milestone-8MigrationGuide-NewURLfordownloadingGradledistributions
 .


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

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

2012-03-18 Thread s.sog...@gmail.com (JIRA) 

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

sogabe commented on JENKINS-13129:
--

JENKINS-12514 will be fixed in 1.456. See http://jenkins-ci.org/changelog.

> Updating built-in plugins doesn't work, the file doesn't get pinned and is 
> overwritten on the next startup
> --
>
> Key: JENKINS-13129
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13129
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: jenkins 1.457-snapshot, tomcat 7.0.25, java 1.6.0-31 
> running on windows vista
> jenkins 1.455, tomcat 7.0.26, java 1.6.0-31 running on ubuntu 11.10
>Reporter: Alex Lehmann
>
> I still cannot update cvs or subversion plugins without manually creating a 
> .pinned file.
> When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file 
> is installed into the plugin dir, but no cvs.jpi.pinned file is created. When 
> restarting the tomcat server, the file is replaced by the 1.6 version from 
> the war directory.
> This is probably related to JENKINS-12514, but wasn't fixed then

--
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-12330) Occasionally,collecting findbugs analysis files will take very long time, event two more hours.

2012-03-18 Thread huang_pe...@vanceinfo.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160386#comment-160386
 ] 

King Hpd commented on JENKINS-12330:


Occasionally,I found findbugs will take very long time to analysis files.Some 
time it will take two more hours. 
Just stop at: 
[FINDBUGS] Collecting findbugs analysis files... 

And I had to kill the process. 

This is the dump information when I kill the process 
ERROR: Publisher hudson.plugins.findbugs.FindBugsPublisher aborted due to 
exception 
java.lang.InterruptedException 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:979)
 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
 
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218) 
at java.util.concurrent.FutureTask.get(FutureTask.java:83) 
at hudson.remoting.Request.call(Request.java:138) 
at hudson.remoting.Channel.call(Channel.java:681) 
at hudson.FilePath.act(FilePath.java:777) 
at hudson.FilePath.act(FilePath.java:770) 
at hudson.FilePath.copyTo(FilePath.java:1514) 
at 
hudson.plugins.analysis.core.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:392)
 
at 
hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:354)
 
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) 
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
 
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653)
 
at hudson.model.Build$RunnerImpl.post2(Build.java:162) 
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622) 
at hudson.model.Run.run(Run.java:1434) 
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 
at hudson.model.ResourceController.execute(ResourceController.java:88) 
at hudson.model.Executor.run(Executor.java:238)


Please help me to look into this bug.

Thanks 
hpd_king

> Occasionally,collecting findbugs analysis files will take very long time, 
> event two more hours.
> ---
>
> Key: JENKINS-12330
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12330
> Project: Jenkins
>  Issue Type: Bug
>  Components: findbugs
>Affects Versions: current
> Environment: ubuntu 10.04 LTS
>Reporter: roger four
>Assignee: Ulli Hafner
>  Labels: plugin
>
> Occasionally,I found findbugs will take very long time to analysis files.Some 
> time it will take two more hours.
> Just stop at:
> [FINDBUGS] Collecting findbugs analysis files...
> And I had to kill the process.
> It bothers me very much.Pls help me.
> 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-1948) intermittent: fails to remove temporary file on remote.

2012-03-18 Thread boi...@gmail.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160385#comment-160385
 ] 

Ben Ernst commented on JENKINS-1948:


I think I'm seeing much the same issue here, ubuntu master, windows slave, 
jenkins 1.455.

{code}
09:50:06   [exec] 1>ClCompile:
09:50:06   [exec] 1>  appsvcs.cpp
09:50:26   [exec] 1>  All outputs are up-to-date.
09:52:39  FATAL: Unable to delete script file 
C:\Windows\TEMP\hudson7112635489663392827.bat
09:52:39  hudson.util.IOException2: remote file operation failed: 
C:\Windows\TEMP\hudson7112635489663392827.bat at 
hudson.remoting.Channel@504f4373:Sue
09:52:39at hudson.FilePath.act(FilePath.java:784)
09:52:39at hudson.FilePath.act(FilePath.java:770)
09:52:39at hudson.FilePath.delete(FilePath.java:1075)
09:52:39at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92)
09:52:39at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
09:52:39at 
hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
09:52:39at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
09:52:39at hudson.model.Build$RunnerImpl.build(Build.java:178)
09:52:39at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
09:52:39at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
09:52:39at hudson.model.Run.run(Run.java:1410)
09:52:39at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
09:52:39at 
hudson.model.ResourceController.execute(ResourceController.java:88)
09:52:39at hudson.model.Executor.run(Executor.java:238)
09:52:39  Caused by: hudson.remoting.ChannelClosedException: channel is already 
closed
09:52:39at hudson.remoting.Channel.send(Channel.java:499)
09:52:39at hudson.remoting.Request.call(Request.java:110)
09:52:39at hudson.remoting.Channel.call(Channel.java:681)
09:52:39at hudson.FilePath.act(FilePath.java:777)
09:52:39... 13 more
09:52:39  Caused by: java.net.SocketException: Connection reset
09:52:39at java.net.SocketInputStream.read(SocketInputStream.java:185)
09:52:39at java.io.FilterInputStream.read(FilterInputStream.java:133)
09:52:39at 
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
09:52:39at 
java.io.BufferedInputStream.read(BufferedInputStream.java:254)
09:52:39at 
java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2265)
09:52:39at 
java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2558)
09:52:39at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2568)
09:52:39at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314)
09:52:39at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
09:52:39at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127)
09:52:39  FATAL: hudson.remoting.RequestAbortedException: 
java.net.SocketException: Connection reset
09:52:39  hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection 
reset
09:52:39at hudson.remoting.Request.call(Request.java:149)
09:52:39at hudson.remoting.Channel.call(Channel.java:681)
09:52:39at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
09:52:39at $Proxy42.join(Unknown Source)
09:52:39at 
hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:859)
09:52:39at hudson.Launcher$ProcStarter.join(Launcher.java:345)
09:52:39at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82)
09:52:39at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
09:52:39at 
hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
09:52:39at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
09:52:39at hudson.model.Build$RunnerImpl.build(Build.java:178)
09:52:39at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
09:52:39at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
09:52:39at hudson.model.Run.run(Run.java:1410)
09:52:39at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
09:52:39at 
hudson.model.ResourceController.execute(ResourceController.java:88)
09:52:39at hudson.model.Executor.run(Executor.java:238)
09:52:39  Caused by: hudson.remoting.RequestAbortedException: 
java.net.SocketException: Connection reset
09:52:39at hudson.remoting.Request.abort(Request.java:273)
09:52:39at hudson.remoting.Channel.terminate(Channel.java:732)
09:52:39at hudson.remoting.Channel$ReaderThread.run(Channel.java:1157)
09:52:39  Caused by: java.net.SocketException: Con

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

2012-03-18 Thread alexl...@gmail.com (JIRA) 
Alex Lehmann created JENKINS-13129:
--

 Summary: Updating built-in plugins doesn't work, the file doesn't 
get pinned and is overwritten on the next startup
 Key: JENKINS-13129
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13129
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: jenkins 1.457-snapshot, tomcat 7.0.25, java 1.6.0-31 
running on windows vista
jenkins 1.455, tomcat 7.0.26, java 1.6.0-31 running on ubuntu 11.10

Reporter: Alex Lehmann


I still cannot update cvs or subversion plugins without manually creating a 
.pinned file.

When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file 
is installed into the plugin dir, but no cvs.jpi.pinned file is created. When 
restarting the tomcat server, the file is replaced by the 1.6 version from the 
war directory.

This is probably related to JENKINS-12514, but wasn't fixed then


--
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-13113) Xunit Plugin detects MSTEST "NotExecuted" as "Passed" instead of "Skipped"

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

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160384#comment-160384
 ] 

gbois commented on JENKINS-13113:
-

Do you have the same issue with the independent MSTest Jenkins plugins?
Thanks

> Xunit Plugin detects MSTEST "NotExecuted" as "Passed" instead of "Skipped"
> --
>
> Key: JENKINS-13113
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13113
> Project: Jenkins
>  Issue Type: Bug
>  Components: xunit
>Affects Versions: current
> Environment: Jenkins 1.455
> xunit 1.40
>Reporter: Dirk Kuypers
>Assignee: gbois
>
> We had an out of memory exception while running our MSTEST unit tests which 
> caused all subsequent tests to be NotExecuted. Unfortunately those 
> "NotExecuted" tests were counted as passed, so the test job succeeded instead 
> of failing.
> One example from the TRX file:
>  testId="3509a64f-6214-eb24-6628-bd431f93997c" 
> testName="TestcaseWcdmaTxIntermod_5_12__FDD9" computerName="1SP1-SLAVE2" 
> testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="NotExecuted" 
> testListId="8c84fa94-04c1-424b-9868-57a2d4851a1d" 
> relativeResultsDirectory="88518b81-226a-4fe9-9896-774a00c13e8e">
> 
> The transformation in the junitResult.xml file:
>   
>   NaN 
>   ConformanceWcdmaCompleteTest.BandSpecificTests 
>   TestcaseWcdmaTxIntermod_5_12__FDD9 
>   false 
>   0 
>   

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

[JIRA] (JENKINS-13119) How can I set an environment variable based on value of user passed parameter?

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

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160383#comment-160383
 ] 

gbois commented on JENKINS-13119:
-

And for your need, you have to select a custom workspace and use your computed 
variable.

> How can I set an environment variable based on value of user passed parameter?
> --
>
> Key: JENKINS-13119
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13119
> Project: Jenkins
>  Issue Type: Improvement
>  Components: envinject
>Affects Versions: current
> Environment: Redhat Linux 5.5
>Reporter: suresh kukalakuntla
>Assignee: gbois
>
> I want to set value for an environment variable based on user provided input 
> during the build and use this env variable to set workspace in a jenkins 
> project.
> Ex: User has to select MODULE_NAME when performing a build. MODULE_NAME is a 
> choice parameter. Based on the value selected by the user I want to set 
> MODULE_FOLDER environment variable and use it for setting the WORKSPACE.
> Below is the functionality I am expecting.
> if MODULE_NAME is 'A' then set MODULE_FOLDER = FOLDER1
> else if MODULE_NAME is 'B' then set MODULE_FOLDER = FOLDER2
> else if MODULE_NAME is 'C' then set MODULE_FOLDER = FOLDER3
> Now set WORKSPACE=/usr/modules/$MODULE_FOLDER
> Please help me achieve this functionality. I want to have only one job for 
> all modules. Based on the module user selects I want to build it and deploy 
> it.
> your guidance is much appreciated

--
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-13128) Artifacts Permissions Stripped

2012-03-18 Thread cont...@tiernok.com (JIRA) 
Eli Weinstock-Herman created JENKINS-13128:
--

 Summary: Artifacts Permissions Stripped
 Key: JENKINS-13128
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13128
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Centos 5.6, 32-bit, JDK 7u3, Jenkins 1.455
Reporter: Eli Weinstock-Herman


I've seen several related and/or resolved issue on this but I wasn't sure which 
one was relevant for re-opening.

I have a very basic job (name DEV) that polls a git repository, deploys the 
files to a local webserver via a shell script, then archives the workspace. A 
second job then picks up the last successful archive w/ the Copy Artifact 
plugin and attempts to run the same deploy script and receives an error due to 
missing executable permissions. The intent is to put a skeleton together of a 
pipeline for DEV->QA->PROD, each deploying to a local folder (symlinked to a 
directory apache is aware of), the file permissions are deployment scripts are 
managed in the repository with the source for the site.

I initially thought this was an issue with the Copy Artifact plugin, but after 
writing a basic shell script to manually copy the files and then looking 
directly at the archive folders in the job folders, it appears to be the 
Archive operation itself.

It appears that all the file and folder permissions are being set/cleared when 
the archive occurred. The contents of the DEV workspace has original 
permissions after a run, but the archive contents 
(jenkins\jobs\DEV\builds\##\archive) are missing their permissions. All files 
have been set to 644, all directories to 755 (>2000 files in multiple 
subdirectories, although to be fair I've only checked 5 or 6 subdirectories).

This is similar to the related set of tickets under JENKINS-9397 but I wasn't 
sure which (if any) was best to reopen.

--
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-12582) CVS-Plugin: Password file "${user.home}/.cvspass" is ignored under some conditions

2012-03-18 Thread alexl...@gmail.com (JIRA) 

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

Alex Lehmann updated JENKINS-12582:
---

Summary: CVS-Plugin: Password file "${user.home}/.cvspass" is ignored under 
some conditions  (was: CVS-Plugin: Password file "${user.home}/.cvspass" is 
ignored)

> CVS-Plugin: Password file "${user.home}/.cvspass" is ignored under some 
> conditions
> --
>
> Key: JENKINS-12582
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12582
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs
> Environment: Tomcat6 / RHEL5
>Reporter: chrisabit
>Assignee: Alex Lehmann
>Priority: Blocker
>
> Jenkins' new Netbeans-based CVS-Plugin doesn't use the ".cvspass" file. 
> Setting the password on every job isn't a suitable solution (huge number of 
> jobs, security issues). The ".cvspass" file should be used instead.

--
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-13127) Automatic Install blocks forever

2012-03-18 Thread tsuc...@gmail.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160382#comment-160382
 ] 

Thomas Suckow commented on JENKINS-13127:
-

Note this did work before: http://ci.codingwell.net/job/Weave/45/console

> Automatic Install blocks forever
> 
>
> Key: JENKINS-13127
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13127
> Project: Jenkins
>  Issue Type: Bug
>  Components: gradle
> Environment: Slave: Fedora x86
> Master: Amazon-AMI x64
>Reporter: Thomas Suckow
>Assignee: gbois
>
> Installation blocks forever on:
> Unpacking 
> http://services.gradle.org/distributions/gradle-1.0-milestone-9-bin.zip to 
> /home/tsuckow/.jenkins_slave/tools/Gradle_9 on Conure
> I rebooted the slave thinking it might help which resulted in this stack 
> trace:
> FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: 
> Unexpected termination of the channel
> hudson.remoting.RequestAbortedException: 
> hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
> termination of the channel
>   at hudson.remoting.Request.call(Request.java:149)
>   at hudson.remoting.Channel.call(Channel.java:681)
>   at hudson.FilePath.act(FilePath.java:777)
>   at hudson.FilePath.act(FilePath.java:770)
>   at hudson.FilePath.unzipFrom(FilePath.java:467)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:667)
>   at 
> hudson.tools.ZipExtractionInstaller.performInstallation(ZipExtractionInstaller.java:82)
>   at 
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61)
>   at 
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
>   at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:150)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:101)
>   at hudson.plugins.gradle.Gradle.performTask(Gradle.java:146)
>   at hudson.plugins.gradle.Gradle.perform(Gradle.java:97)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
>   at hudson.model.Build$RunnerImpl.build(Build.java:178)
>   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
>   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
>   at hudson.model.Run.run(Run.java:1410)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:238)
> Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
> Unexpected termination of the channel
>   at hudson.remoting.Request.abort(Request.java:273)
>   at hudson.remoting.Channel.terminate(Channel.javaa:732)
>   at hudson.remoting.Channel$ReaderThread.run(Channel.java:1157)
> Caused by: java.io.IOException: Unexpected termination of the channel
>   at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133)
> Caused by: java.io.EOFException
>   at 
> java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
>   at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127)

--
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-13127) Automatic Install blocks forever

2012-03-18 Thread tsuc...@gmail.com (JIRA) 
Thomas Suckow created JENKINS-13127:
---

 Summary: Automatic Install blocks forever
 Key: JENKINS-13127
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13127
 Project: Jenkins
  Issue Type: Bug
  Components: gradle
 Environment: Slave: Fedora x86
Master: Amazon-AMI x64
Reporter: Thomas Suckow
Assignee: gbois


Installation blocks forever on:
Unpacking 
http://services.gradle.org/distributions/gradle-1.0-milestone-9-bin.zip to 
/home/tsuckow/.jenkins_slave/tools/Gradle_9 on Conure

I rebooted the slave thinking it might help which resulted in this stack trace:

FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
at hudson.remoting.Request.call(Request.java:149)
at hudson.remoting.Channel.call(Channel.java:681)
at hudson.FilePath.act(FilePath.java:777)
at hudson.FilePath.act(FilePath.java:770)
at hudson.FilePath.unzipFrom(FilePath.java:467)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:667)
at 
hudson.tools.ZipExtractionInstaller.performInstallation(ZipExtractionInstaller.java:82)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:150)
at 
hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:101)
at hudson.plugins.gradle.Gradle.performTask(Gradle.java:146)
at hudson.plugins.gradle.Gradle.perform(Gradle.java:97)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
at hudson.model.Run.run(Run.java:1410)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
Unexpected termination of the channel
at hudson.remoting.Request.abort(Request.java:273)
at hudson.remoting.Channel.terminate(Channel.javaa:732)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1157)
Caused by: java.io.IOException: Unexpected termination of the channel
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127)

--
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-13126) Empty directories are not uploaded

2012-03-18 Thread philipp.je...@gmx.ch (JIRA) 
Jenni Philipp created JENKINS-13126:
---

 Summary: Empty directories are not uploaded
 Key: JENKINS-13126
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13126
 Project: Jenkins
  Issue Type: Bug
  Components: publish-over-ftp
Affects Versions: current
Reporter: Jenni Philipp
Assignee: bap


If a directory is empty, the plugin doesn't upload it to the ftp server. 

--
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-10866) NullPointerException for SVN authentication using username+password and client certificate

2012-03-18 Thread joh...@gyger.name (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160381#comment-160381
 ] 

Johann Gyger commented on JENKINS-10866:


I haven't been able to make this work with Jenkins 1.455. I tried different 
variations of the described workaround. I still get the exception and it would 
be nice if the radio buttons could be changed so that multiple "authentication" 
options are selectable (certificate and username/password).


> NullPointerException for SVN authentication using username+password and 
> client certificate
> --
>
> Key: JENKINS-10866
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10866
> Project: Jenkins
>  Issue Type: Bug
>  Components: subversion
>Affects Versions: current
> Environment: OpenSuSE 11.2, jenkins-1.428-1.2 installed using package 
> manager, upgrade from hudson 1.373 package
>Reporter: Staffan Olsson
>
> The Subversion server uses both client certificate and username+password. 
> I've configured authentication as described in JENKINS-3912. I've also tried 
> using a fresh .subversion dir, as described in JENKINS-4037 although that bug 
> has a different NPE than this.
> The client certificate part probably goes well, because after adding my cert 
> and its password I get the authentication error details saying "401 
> Authentication Required":
> {quote}
> Attempting an SSL client certificate authentcation
> Passing user name null and password you entered
> Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS 
> of /svn/project/trunk: 401 Authorization
> {quote}
> But when adding login username and password I get:
> {quote}
> Attempting an SSL client certificate authentcation
> FAILED: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS 
> /svn/project/trunk failed
> org.tmatesoft.svn.core.SVNException: svn: OPTIONS /svn/project/trunk failed
>   at 
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
>   at 
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97)
>   at 
> hudson.scm.SubversionSCM$DescriptorImpl.postCredential(SubversionSCM.java:1857)
>   at 
> hudson.scm.SubversionSCM$DescriptorImpl.doPostCredential(SubversionSCM.java:1802)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:616)
>   at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
>   at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
>   at 
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
>   at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
>   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:249)
>   at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
>   at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
>   at 
> hudson.util.PluginSe

[JIRA] (JENKINS-12582) CVS-Plugin: Password file "${user.home}/.cvspass" is ignored

2012-03-18 Thread alexl...@gmail.com (JIRA) 

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

Alex Lehmann resolved JENKINS-12582.


Resolution: Fixed

> CVS-Plugin: Password file "${user.home}/.cvspass" is ignored
> 
>
> Key: JENKINS-12582
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12582
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs
> Environment: Tomcat6 / RHEL5
>Reporter: chrisabit
>Assignee: Alex Lehmann
>Priority: Blocker
>
> Jenkins' new Netbeans-based CVS-Plugin doesn't use the ".cvspass" file. 
> Setting the password on every job isn't a suitable solution (huge number of 
> jobs, security issues). The ".cvspass" file should be used instead.

--
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-12582) CVS-Plugin: Password file "${user.home}/.cvspass" is ignored

2012-03-18 Thread alexl...@gmail.com (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160380#comment-160380
 ] 

Alex Lehmann commented on JENKINS-12582:


the fix is included in cvs-plugin 2.1


> CVS-Plugin: Password file "${user.home}/.cvspass" is ignored
> 
>
> Key: JENKINS-12582
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12582
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs
> Environment: Tomcat6 / RHEL5
>Reporter: chrisabit
>Assignee: Alex Lehmann
>Priority: Blocker
>
> Jenkins' new Netbeans-based CVS-Plugin doesn't use the ".cvspass" file. 
> Setting the password on every job isn't a suitable solution (huge number of 
> jobs, security issues). The ".cvspass" file should be used instead.

--
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-13125) HTTP Content-Range Header one byte past file length

2012-03-18 Thread rol...@utk.edu (JIRA) 
Roland Schulz created JENKINS-13125:
---

 Summary: HTTP Content-Range Header one byte past file length
 Key: JENKINS-13125
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13125
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Roland Schulz


Downloading a PDF artifact using Chrome (17.0.963.79 m on Windows) the HTTP 
header for the last partial entity-body sent back by Jenkins contains:
Content-Range: 2613923-2646691/2646691\r\n
I believe this is wrong according to 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16 . I believe the 
last range should be 2613923-2646690/2646691, because the numbers are 0-indexed.

I'm not sure whether this is caused by this or is a separate issue, but Chrome 
keeps requesting the same last partial segment and Jenkins returns the same one 
in an endless loop. Thus Chrome is stuck loading the PDF at 100% in the endless 
loop. This only happens with the Chrome embedded PDF viewer. The file downloads 
correctly with "Save as". 

--
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-13101) Analysis Collector Plugin prevents other plugins from loading when the Dashboard View Plugin is not installed

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

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160379#comment-160379
 ] 

Ulli Hafner commented on JENKINS-13101:
---

Did you also install the analysis-core plug-in? This is required for the 
analysis-collector.

Maybe something in Jenkins core class loading has been changed that causes this 
issue. I'll try to reproduce on 1.455.

What I don't understand from the log is: 
{noformat}
INFO: Plugin dashboard-view.jpi is disabled
{noformat}

Didn't you say the plugin is not installed? Do you still have a view using the 
dashboard view? This might be the reason for the exception message. (And is 
unrelated to your problem)

> Analysis Collector Plugin prevents other plugins from loading when the 
> Dashboard View Plugin is not installed
> -
>
> Key: JENKINS-13101
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13101
> Project: Jenkins
>  Issue Type: Bug
>  Components: analysis-collector
>Affects Versions: current
> Environment: Jenkins ver. 1.455
> Analysis Collector 1.20
> Tomcat 6 
>Reporter: Martin Ziel
>Assignee: Ulli Hafner
>  Labels: exception, plugin
> Attachments: jenkins.log
>
>
> The Analysis Collector Plugin prevents other plugins from loading when the 
> Dashboard View Plugin is not installed and activated. In my case, this 
> effectively disables the SCM Plugins and thus prevents Jenkins from fetching 
> SCM changes. Log attached.

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

[JIRA] (JENKINS-8043) "Reload Configuration from Disk" loses labels for swarm-clients

2012-03-18 Thread dogf...@java.net (JIRA) 

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

dogfood commented on JENKINS-8043:
--

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

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


> "Reload Configuration from Disk" loses labels for swarm-clients
> ---
>
> Key: JENKINS-8043
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8043
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: voorth
>Assignee: abayer
>


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

[JIRA] (JENKINS-8043) "Reload Configuration from Disk" loses labels for swarm-clients

2012-03-18 Thread s.sog...@gmail.com (JIRA) 

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

sogabe resolved JENKINS-8043.
-

Resolution: Fixed

> "Reload Configuration from Disk" loses labels for swarm-clients
> ---
>
> Key: JENKINS-8043
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8043
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: voorth
>Assignee: abayer
>


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

[JIRA] (JENKINS-8043) "Reload Configuration from Disk" loses labels for swarm-clients

2012-03-18 Thread scm_issue_l...@java.net (JIRA) 

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

SCM/JIRA link daemon commented on JENKINS-8043:
---

Code changed in jenkins
User: Marc Guenther
Path:
 core/src/main/java/jenkins/model/Jenkins.java
http://jenkins-ci.org/commit/jenkins/24c31d138fe7b9ff14870b921220bdf709af20cc
Log:
  [Fixed JENKINS-8043] "Reload Configuration from Disk" broke swarm clients

When Reloading Configuration from Disk in Jenkins, all swarm clients
were in an unusable state afterwards (eg. missing their labels).
This happened because Swarm Clients were not written into the
configuration file, and got removed when reloading the config.

This patch re-adds all previously existing swarm clients after
reloading the config file.




> "Reload Configuration from Disk" loses labels for swarm-clients
> ---
>
> Key: JENKINS-8043
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8043
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: voorth
>Assignee: abayer
>


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

[JIRA] (JENKINS-11663) Swarm Client fails to connect to Jenkins when Authentication is enabled but Authorization is diabled

2012-03-18 Thread s.sog...@gmail.com (JIRA) 

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

sogabe resolved JENKINS-11663.
--

Resolution: Fixed

> Swarm Client fails to connect to Jenkins when Authentication is enabled but 
> Authorization is diabled
> 
>
> Key: JENKINS-11663
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11663
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: Nicholas Hall
>Assignee: sogabe
>Priority: Trivial
> Attachments: Client.java.diff
>
>
> We have enabled LDAP authentication for Jenkins, but do not have 
> authorization enabled ('Anyone can do anything').
> We do not pass a username or password for the swarm clients.  This results in 
> a 401 during the jnlp connection phase.
> I've attached a very simple code change to hudson.plugins.swarm.Client.java 
> that works in our environment.  Under the condition that a username and 
> password aren't available, do not add the '-credential' switch to the Main 
> args.

--
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-11663) Swarm Client fails to connect to Jenkins when Authentication is enabled but Authorization is diabled

2012-03-18 Thread dogf...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160376#comment-160376
 ] 

dogfood commented on JENKINS-11663:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_swarm 
#33|http://ci.jenkins-ci.org/job/plugins_swarm/33/]
 [JENKINS-11663] Swarm Client fails to connect to Jenkins when 
Authentication is enabled but (Revision 
992f49199868f0e9d8698aa48a93428b177eb018)

 Result = SUCCESS
Seiji Sogabe : 
Files : 
* client/src/main/java/hudson/plugins/swarm/Client.java


> Swarm Client fails to connect to Jenkins when Authentication is enabled but 
> Authorization is diabled
> 
>
> Key: JENKINS-11663
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11663
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: Nicholas Hall
>Assignee: sogabe
>Priority: Trivial
> Attachments: Client.java.diff
>
>
> We have enabled LDAP authentication for Jenkins, but do not have 
> authorization enabled ('Anyone can do anything').
> We do not pass a username or password for the swarm clients.  This results in 
> a 401 during the jnlp connection phase.
> I've attached a very simple code change to hudson.plugins.swarm.Client.java 
> that works in our environment.  Under the condition that a username and 
> password aren't available, do not add the '-credential' switch to the Main 
> args.

--
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-11663) Swarm Client fails to connect to Jenkins when Authentication is enabled but Authorization is diabled

2012-03-18 Thread scm_issue_l...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160375#comment-160375
 ] 

SCM/JIRA link daemon commented on JENKINS-11663:


Code changed in jenkins
User: Seiji Sogabe
Path:
 client/src/main/java/hudson/plugins/swarm/Client.java
http://jenkins-ci.org/commit/swarm-plugin/992f49199868f0e9d8698aa48a93428b177eb018
Log:
  [JENKINS-11663] Swarm Client fails to connect to Jenkins when Authentication 
is enabled but
Authorization is diabled


Compare: https://github.com/jenkinsci/swarm-plugin/compare/54bf000...992f491



> Swarm Client fails to connect to Jenkins when Authentication is enabled but 
> Authorization is diabled
> 
>
> Key: JENKINS-11663
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11663
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: Nicholas Hall
>Assignee: sogabe
>Priority: Trivial
> Attachments: Client.java.diff
>
>
> We have enabled LDAP authentication for Jenkins, but do not have 
> authorization enabled ('Anyone can do anything').
> We do not pass a username or password for the swarm clients.  This results in 
> a 401 during the jnlp connection phase.
> I've attached a very simple code change to hudson.plugins.swarm.Client.java 
> that works in our environment.  Under the condition that a username and 
> password aren't available, do not add the '-credential' switch to the Main 
> args.

--
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-11663) Swarm Client fails to connect to Jenkins when Authentication is enabled but Authorization is diabled

2012-03-18 Thread s.sog...@gmail.com (JIRA) 

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

sogabe reassigned JENKINS-11663:


Assignee: sogabe  (was: Kohsuke Kawaguchi)

> Swarm Client fails to connect to Jenkins when Authentication is enabled but 
> Authorization is diabled
> 
>
> Key: JENKINS-11663
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11663
> Project: Jenkins
>  Issue Type: Bug
>  Components: swarm
>Reporter: Nicholas Hall
>Assignee: sogabe
>Priority: Trivial
> Attachments: Client.java.diff
>
>
> We have enabled LDAP authentication for Jenkins, but do not have 
> authorization enabled ('Anyone can do anything').
> We do not pass a username or password for the swarm clients.  This results in 
> a 401 during the jnlp connection phase.
> I've attached a very simple code change to hudson.plugins.swarm.Client.java 
> that works in our environment.  Under the condition that a username and 
> password aren't available, do not add the '-credential' switch to the Main 
> args.

--
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-13124) Missing "New warnings"

2012-03-18 Thread rol...@utk.edu (JIRA) 
Roland Schulz created JENKINS-13124:
---

 Summary: Missing "New warnings" 
 Key: JENKINS-13124
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13124
 Project: Jenkins
  Issue Type: Bug
  Components: warnings
Reporter: Roland Schulz
Assignee: Ulli Hafner


I noticed a case in which the warnings surrounding a modified line are not 
shown as "new warnings". But according to: 
https://issues.jenkins-ci.org/browse/JENKINS-6675 they should be shown because 
the warnings are within +/-3 line of the modified line. I assume that the 
warnings plugin is taken the modified lines from the SCM.

The file was changed in line 77 (see 4) but the surrounding warnings (see 1) 
are not shown in the "New warnings" (see 2).
1) The warnings: 
http://jenkins.gromacs.org/view/Gerrit%20Docu/job/Doxygen_Gerrit_master/65/warningsResult/package.689474037/file.-1578484055/
2) 0 new warngins: 
http://jenkins.gromacs.org/view/Gerrit%20Docu/job/Doxygen_Gerrit_master/65/warningsResult/new/
3) Showing that the file was changed: 
http://jenkins.gromacs.org/view/Gerrit%20Docu/job/Doxygen_Gerrit_master/65/changes#detail0
4) Showing the diff for the file: 
https://gerrit.gromacs.org/#/c/517/13/src/gromacs/trajectoryanalysis/runnercommon.h

Maybe interesting the new warning detection did work correctly with an earlier 
reference build.
For that build, the new warnings were detected correctly: 
http://jenkins.gromacs.org/view/Gerrit%20Docu/job/Doxygen_Gerrit_master/59/warningsResult/new/package.689474037.
The file changed exactly the same  for build 59 and build 65. 

The plugins and Jenkins is the latest version.

Please let me know if I can provide any further information. 

--
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-13119) How can I set an environment variable based on value of user passed parameter?

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

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160374#comment-160374
 ] 

gbois edited comment on JENKINS-13119 at 3/18/12 9:51 AM:
--

I added the ability to evaluate a Groovy script in 'Prepare environment for the 
build' section

For example, you can have the following script:
if (CASE==null){
  return null; 
} 

def stringValue="StRinG"; 

if ("upper".equals(CASE)){ 
   def map = [COMPUTE_VAR: stringValue.toUpperCase()]
   return map 
 } 

if ("lower".equals(CASE)){ 
  def map = [COMPUTE_VAR: stringValue.toLowerCase()]
  return map
} 

This script injects the environment COMPUTE_VAR in the following job steps.
As you can see, this variable is computed according the CASE variable value.
This variable comes from a parameter value (given by the user).

The only restrictions are:
- The script has to be in Groovy (close to Jenkins core, written in Java/Groovy)
- The script has to return a Map Java object (all the map elements will 
exported as environment variables).

Please upgrade to EnvInject 1.38.
Let me know if it suits you.





  was (Author: gbois):
I added the ability to evaluate a Groovy script in 'Prepare environment for 
the build' section

For example, you can have the following script:
if (CASE==null){
  return null; 
} 

def stringValue="StRinG"; 

if ("upper".equals(CASE)){ 
   def map = [COMPUTE_VAR: stringValue.toUpperCase()]
   return map 
 } 

if ("lower".equals(CASE)){ 
  def map = [COMPUTE_VAR: stringValue.toLowerCase()]
  return map
} 

This script injects the environment COMPUTE_VAR in the following job steps.
As you see, this variable is computed according the CASE variable value.
This variable comes from a parameter value (given by the user).

The only restrictions are:
- The script has to be in Groovy (close to Jenkins core, written in Java/Groovy)
- The script has to return a Map Java object (all the map elements will 
exported as environment variables).

Please upgrade to EnvInject 1.38.
Let me know if it suits you.




  
> How can I set an environment variable based on value of user passed parameter?
> --
>
> Key: JENKINS-13119
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13119
> Project: Jenkins
>  Issue Type: Improvement
>  Components: envinject
>Affects Versions: current
> Environment: Redhat Linux 5.5
>Reporter: suresh kukalakuntla
>Assignee: gbois
>
> I want to set value for an environment variable based on user provided input 
> during the build and use this env variable to set workspace in a jenkins 
> project.
> Ex: User has to select MODULE_NAME when performing a build. MODULE_NAME is a 
> choice parameter. Based on the value selected by the user I want to set 
> MODULE_FOLDER environment variable and use it for setting the WORKSPACE.
> Below is the functionality I am expecting.
> if MODULE_NAME is 'A' then set MODULE_FOLDER = FOLDER1
> else if MODULE_NAME is 'B' then set MODULE_FOLDER = FOLDER2
> else if MODULE_NAME is 'C' then set MODULE_FOLDER = FOLDER3
> Now set WORKSPACE=/usr/modules/$MODULE_FOLDER
> Please help me achieve this functionality. I want to have only one job for 
> all modules. Based on the module user selects I want to build it and deploy 
> it.
> your guidance is much appreciated

--
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-13119) How can I set an environment variable based on value of user passed parameter?

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

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

gbois resolved JENKINS-13119.
-

Resolution: Fixed

I added the ability to evaluate a Groovy script in 'Prepare environment for the 
build' section

For example, you can have the following script:
if (CASE==null){
  return null; 
} 

def stringValue="StRinG"; 

if ("upper".equals(CASE)){ 
   def map = [COMPUTE_VAR: stringValue.toUpperCase()]
   return map 
 } 

if ("lower".equals(CASE)){ 
  def map = [COMPUTE_VAR: stringValue.toLowerCase()]
  return map
} 

This script injects the environment COMPUTE_VAR in the following job steps.
As you see, this variable is computed according the CASE variable value.
This variable comes from a parameter value (given by the user).

The only restrictions are:
- The script has to be in Groovy (close to Jenkins core, written in Java/Groovy)
- The script has to return a Map Java object (all the map elements will 
exported as environment variables).

Please upgrade to EnvInject 1.38.
Let me know if it suits you.





> How can I set an environment variable based on value of user passed parameter?
> --
>
> Key: JENKINS-13119
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13119
> Project: Jenkins
>  Issue Type: Improvement
>  Components: envinject
>Affects Versions: current
> Environment: Redhat Linux 5.5
>Reporter: suresh kukalakuntla
>Assignee: gbois
>
> I want to set value for an environment variable based on user provided input 
> during the build and use this env variable to set workspace in a jenkins 
> project.
> Ex: User has to select MODULE_NAME when performing a build. MODULE_NAME is a 
> choice parameter. Based on the value selected by the user I want to set 
> MODULE_FOLDER environment variable and use it for setting the WORKSPACE.
> Below is the functionality I am expecting.
> if MODULE_NAME is 'A' then set MODULE_FOLDER = FOLDER1
> else if MODULE_NAME is 'B' then set MODULE_FOLDER = FOLDER2
> else if MODULE_NAME is 'C' then set MODULE_FOLDER = FOLDER3
> Now set WORKSPACE=/usr/modules/$MODULE_FOLDER
> Please help me achieve this functionality. I want to have only one job for 
> all modules. Based on the module user selects I want to build it and deploy 
> it.
> your guidance is much appreciated

--
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-4898) Poll SCM trigger mechanism

2012-03-18 Thread michael.m.cla...@gmail.com (JIRA) 

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

Michael Clarke updated JENKINS-4898:


Component/s: core

Whilst CVS is mentioned in the description, this issue actually needs changes 
in the core. Adding core as affected component

> Poll SCM trigger mechanism
> --
>
> Key: JENKINS-4898
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4898
> Project: Jenkins
>  Issue Type: Improvement
>  Components: core, cvs
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: tsondergaard
>
> Triggering builds using a CVS commit hook has significant advantages compared 
> to
> polling, specifically builds are started immediately and the CVS server is 
> less
> loaded as it is not being polled constantly.
> It would be very nice if it was possible to trigger hudson to poll CVS when
> triggered, ie. instead of configuring hudson to poll on a schedule it should 
> be
> possible to configure a job to poll CVS when triggered.
> I imagine there could be another text field in the job configuration page when
> Poll SCM is checked where an scm/trigger-id can be specified. The job should
> then poll when an url like the following is invoked (from a commit hook):
> wget -O - http://YOURHUDSON/poll_scm?scm=

--
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-13119) How can I set an environment variable based on value of user passed parameter?

2012-03-18 Thread scm_issue_l...@java.net (JIRA) 

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160371#comment-160371
 ] 

SCM/JIRA link daemon commented on JENKINS-13119:


Code changed in jenkins
User: Gregory Boissinot
Path:
 src/main/java/hudson/plugins/envfile/EnvFileBuildWrapper.java
 src/main/java/hudson/plugins/setenv/SetEnvBuildWrapper.java
 src/main/java/org/jenkinsci/plugins/envinject/EnvInjectJobPropertyInfo.java
 src/main/java/org/jenkinsci/plugins/envinject/EnvInjectListener.java
 src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectEnvVars.java
 
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectScriptExecutor.java
 
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectJobProperty/config.jelly
 
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectJobProperty/help-groovyScriptContent.html
 
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectJobProperty/help-keepBuildVariables.html
 src/main/webapp/help.html
 src/test/java/org/jenkinsci/plugins/envinject/EnvInjectBuildWrapperTest.java
http://jenkins-ci.org/commit/envinject-plugin/257acc17f1ae1560f95270d1c24aebc6b60d0261
Log:
  Fix JENKINS-13119






> How can I set an environment variable based on value of user passed parameter?
> --
>
> Key: JENKINS-13119
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13119
> Project: Jenkins
>  Issue Type: Improvement
>  Components: envinject
>Affects Versions: current
> Environment: Redhat Linux 5.5
>Reporter: suresh kukalakuntla
>Assignee: gbois
>
> I want to set value for an environment variable based on user provided input 
> during the build and use this env variable to set workspace in a jenkins 
> project.
> Ex: User has to select MODULE_NAME when performing a build. MODULE_NAME is a 
> choice parameter. Based on the value selected by the user I want to set 
> MODULE_FOLDER environment variable and use it for setting the WORKSPACE.
> Below is the functionality I am expecting.
> if MODULE_NAME is 'A' then set MODULE_FOLDER = FOLDER1
> else if MODULE_NAME is 'B' then set MODULE_FOLDER = FOLDER2
> else if MODULE_NAME is 'C' then set MODULE_FOLDER = FOLDER3
> Now set WORKSPACE=/usr/modules/$MODULE_FOLDER
> Please help me achieve this functionality. I want to have only one job for 
> all modules. Based on the module user selects I want to build it and deploy 
> it.
> your guidance is much appreciated

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