date:20120319

2012-03-19 Thread sebastian.sickelm...@continentale.de (JIRA)

Myron n/a created JENKINS-13133:
---

 Summary: Permission denied due to wrong file system permissions 
upon update/checkout.
 Key: JENKINS-13133
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13133
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Jenkins 1.455 - bunch of plugins
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Default locale: en_US, platform encoding: ISO8859-15
OS name: sunos, version: 5.10, arch: sparc, family: unix

Reporter: Myron n/a


Currently we are using subversion plugin v1.32 - everything works fine.
But after upgrading to the latest v1.39 we encounter some weird behavior:

Upon SVN update i often see a permission denied exception.
(well, update works, but the compiler plugin afterwards reports the permission 
denied)
The updated file has not the (chmod 664) permission as supposed to be, it only 
has execute rights (chmod 001)?!

I dunno when this happens or how to get more SVN logging to narrow this down.
Or what changes from .32 to .39 could be the culprit (svnkit upgrade?)
But reverting back to .32 solves this problem immediately

--
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-13134) Disk usage link doesn't work for view tabs

2012-03-19 Thread gentoo.inte...@gmail.com (JIRA)

Kanstantsin Shautsou created JENKINS-13134:
--

 Summary: Disk usage link doesn't work for view tabs
 Key: JENKINS-13134
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13134
 Project: Jenkins
  Issue Type: Bug
  Components: disk-usage
Affects Versions: current
 Environment: rhel, jenkins-1.455, disk-usage-plugin-0.15 
Reporter: Kanstantsin Shautsou
Assignee: vjuranek
Priority: Minor


Disk usage link doesn't work for view tabs.
Create view, add jobs, go to view, click Disk Usage.

--
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-13135) Very large console logs will cause Jenkins to crash or behave erratically

2012-03-19 Thread da...@orionrobots.co.uk (JIRA)

Danny Staple created JENKINS-13135:
--

 Summary: Very large console logs will cause Jenkins to crash or 
behave erratically
 Key: JENKINS-13135
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13135
 Project: Jenkins
  Issue Type: Bug
  Components: core
 Environment: Linux, FC13
Java:   Java(TM) SE Runtime Environment, 1.6.0_21-b06
JVM:Java HotSpot(TM) 64-Bit Server VM, 17.0-b16, mixed mode
Server:  Apache Tomcat/6.0.20
JVM arguments:  -Xms1024m
-Xmx4096m
-Dhudson.model.WorkspaceCleanupThread.disabled=true
-Dcatalina.base=/usr/share/tomcat6
-Dcatalina.home=/usr/share/tomcat6
-Djava.endorsed.dirs=
-Djava.io.tmpdir=/var/cache/tomcat6/temp
-Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Reporter: Danny Staple


When console logs are exceptionally large (due to user parameters we've had a 
3Gb log go through at some point), and somebody tries to view this log, Jenkins 
will throw an exception there, and may also deny allocations to other threads - 
side effects being disconnected slave nodes, jobs failing to finish up 
correctly.

Exception from catalina log:

{code()}
Mar 16, 2012 4:45:30 PM hudson.ExpressionFactory2$JexlExpression evaluate
WARNING: Caught exception evaluating: item.why. Reason: 
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor321.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
at 
org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
at 
org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
at 
org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75)
at 
org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at 
org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at 
org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
at 
org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
at 
hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72)
at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsString(ExpressionSupport.java:46)
at 
org.apache.commons.jelly.expression.CompositeExpression.evaluateAsString(CompositeExpression.java:256)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.buildAttributes(ReallyStaticTagLibrary.java:111)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:95)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at

[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)

2012-03-19 Thread gray...@gmail.com (JIRA)

Alex Gray created JENKINS-13136:
---

 Summary: Environment Variable Injection injecting (and overriding) 
unwanted variables (ie JAVA_HOME)
 Key: JENKINS-13136
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13136
 Project: Jenkins
  Issue Type: Bug
  Components: envinject
Affects Versions: current
 Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
Slave Node: Windows XP
EnvInject: 1.36
Reporter: Alex Gray
Assignee: gbois


We were using EnvInject 1.35 in various free-style jobs, but after we upgraded 
to 1.36 jobs started failing.
This is the reason:
1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is 
pointing to version 1.25.  I can verify this by going to Jenkins-Manage 
Jenkins-Manage Nodes-MyWinXPNode-view log, and sure enough the node's 
environment variables have JAVA_HOME pointing to 1.25
2) After upgraded to EnvInject 1.36, the jobs started failing because JAVA_HOME 
has been overwritten to 1.27, which does not exist on the node.  In fact, I 
don't know where this is being set because the master does not have java 1.27 
either!

The only option that is is present in the job is this:
Inject environment variables to the build process
Properties Content:
TEMP=c:\\windows\\temp
TMP=c:\\windows\\temp
(everything else under Inject Environment Variables is blank.

I have not tried the latest version, 1.38, but I will, since all the jobs are 
currently broken and I have nothing else to lose...

If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but that 
does not work on multiconfiguration jobs.

I'll keep you posted.  If this is fixed in 1.38, I will update this Jira.



--
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-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)

2012-03-19 Thread gray...@gmail.com (JIRA)


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

Alex Gray commented on JENKINS-13136:
-

I found this on 1.36, so I installed 1.38 and the problem is fixed! Thanks!

 Environment Variable Injection injecting (and overriding) unwanted variables 
 (ie JAVA_HOME)
 ---

 Key: JENKINS-13136
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13136
 Project: Jenkins
  Issue Type: Bug
  Components: envinject
Affects Versions: current
 Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
 Slave Node: Windows XP
 EnvInject: 1.36
Reporter: Alex Gray
Assignee: gbois

 We were using EnvInject 1.35 in various free-style jobs, but after we 
 upgraded to 1.36 jobs started failing.
 This is the reason:
 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is 
 pointing to version 1.25.  I can verify this by going to Jenkins-Manage 
 Jenkins-Manage Nodes-MyWinXPNode-view log, and sure enough the node's 
 environment variables have JAVA_HOME pointing to 1.25
 2) After upgraded to EnvInject 1.36, the jobs started failing because 
 JAVA_HOME has been overwritten to 1.27, which does not exist on the node.  In 
 fact, I don't know where this is being set because the master does not have 
 java 1.27 either!
 The only option that is is present in the job is this:
 Inject environment variables to the build process
 Properties Content:
 TEMP=c:\\windows\\temp
 TMP=c:\\windows\\temp
 (everything else under Inject Environment Variables is blank.
 I have not tried the latest version, 1.38, but I will, since all the jobs are 
 currently broken and I have nothing else to lose...
 If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but 
 that does not work on multiconfiguration jobs.
 I'll keep you posted.  If this is fixed in 1.38, I will update this Jira.

--
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-13036) Boost-Test parsing

2012-03-19 Thread matthias.sch...@ar-tracking.de (JIRA)

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

Matthias Scholz commented on JENKINS-13036:
---

Got the logger working now. Using just: XUnitService as logger entry.

It looks like the BuildInfo section is invalid.
Error:
WARNUNG: [xUnit] - At line 1 of
file:/daten/entwicklung/opt/jenkins/jobs/Test_xunit/workspace/ARTSystemNG_test_log.xml:cvc-complex-type.2.4.a:
Invalid content was found starting with element 'BuildInfo'. One of
'{TestSuite}' is expected.

Test file extraction:
?xml version=1.0 encoding=UTF-8?
TestLog
BuildInfo platform=linux compiler=GNU C++ version 4.5.3 stl=GNU
libstdc++ version 20110428 boost=1.46.1/
TestSuite ...
...
/TestSuite
/TestLog

Boost-Test parsing
--

Key: JENKINS-13036
URL: https://issues.jenkins-ci.org/browse/JENKINS-13036
Project: Jenkins
Issue Type: Bug
Components: xunit
Affects Versions: current
Environment: linux kernel 3.2.1
boost 1.46
jenkins 1.454
xunit plugin 1.40
Reporter: Matthias Scholz
Assignee: gbois
Priority: Critical
Labels: plugin
Attachments: test.xml

Hello,
I am trying to connect ourg UnitTest system with Jenkins using xunit plugin.
The boost xml file is generated by using the following command-line
parameters:
--log_level=all --output_format=XML --report_level=no
Giving the output to jenkins gives:
... .xml' for the metric 'BoostTest' is not valid. The result file has been
skipped.
Is there any possibility to validate against the Boost-Test xsd manually? To
investigate the problem. I searched for a XSD file but could not find any
file nor reference.
I also tried to find some uUnit output using the Logger mechanism. The
description on the plugin website does not work
and also did not look as it could work because the build-in help tells a
different syntax. So I tried several Logger like (setting priority to 'all'):
com.thalesgroup.hudson.plugins.xunit.service.XUnitService
com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer
com.thalesgroup.hudson.plugins.xunit.service.XUnitValidationService
com.thalesgroup.hudson.plugins.xunit.service.XUnitReportProcessorService
com.thalesgroup.hudson.plugins.xunit.service.XUnitLog
xUnit
But the xUnit Logger stayed empty.
So sadly I could not provide any debug information, despite the log file.
Regards,
Matthias Scholz

--
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-13036) Boost-Test parsing

2012-03-19 Thread matthias.sch...@ar-tracking.de (JIRA)

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

Matthias Scholz edited comment on JENKINS-13036 at 3/19/12 1:27 PM:

Got the logger working now. Using just: XUnitService as logger entry.

It looks like the BuildInfo section is invalid.
Error:
WARNUNG: [xUnit] - At line 1 of
file:/.../Test_xunit/workspace/ARTSystemNG_test_log.xml:cvc-complex-type.2.4.a:
Invalid content was found starting with element 'BuildInfo'. One of
'{TestSuite}' is expected.

was (Author: matthiasscholz):
Got the logger working now. Using just: XUnitService as logger entry.

Boost-Test parsing
--

[JIRA] (JENKINS-13036) Boost-Test parsing

2012-03-19 Thread matthias.sch...@ar-tracking.de (JIRA)

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

Matthias Scholz updated JENKINS-13036:
--

Issue Type: Improvement (was: Bug)
Priority: Minor (was: Critical)

Boost-Test parsing
--

Key: JENKINS-13036
URL: https://issues.jenkins-ci.org/browse/JENKINS-13036
Project: Jenkins
Issue Type: Improvement
Components: xunit
Affects Versions: current
Environment: linux kernel 3.2.1
boost 1.46
jenkins 1.454
xunit plugin 1.40
Reporter: Matthias Scholz
Assignee: gbois
Priority: Minor
Labels: plugin
Attachments: test.xml

[JIRA] (JENKINS-10484) SVN_REVISION environment variable is not set when using parameterized Repository URL


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

Sebastian Sickelmann commented on JENKINS-10484:


We have the same problem with 1.424.1 (not tried 1.424.6 yet)

We are using jenkins to build our refactoring branches(we do a refactoring 
phase at the end of each sprint iteration). The URL looks like: 
http://servername/svn/path/refactoting-branches/${akt_refactoring_branch}/projektname

The checkout (via manual trigger) before the build works fine. Only the 
automatic polling does not work.


 SVN_REVISION environment variable is not set when using parameterized 
 Repository URL
 

 Key: JENKINS-10484
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10484
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: windows 2003 server, Jenkins 1.421, Subversion Plugin 
 1.2.8
Reporter: Erez Harari
Priority: Critical

 I'm using a single Repository URL with parameterized value: 
 ${SVN_URL}/application, where SVN_URL is defined as a node level parameter. 
 in that case SVN_REVISION environment variable is not set.
 When using a clear text Repository URL all works 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-12124) random NoClassDefFoundError: hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded


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

Myron n/a commented on JENKINS-12124:
-

what exception are you now observing?
For me, with actual Jenkins 1.455 (as WAR) the java.lang.NoClassDefFoundError: 
hudson/plugins/analysis/core/AbstractProjectAction is gone (thanks Ulli).

Unfortunately, i'm now also seeing the java.lang.NoClassDefFoundError: 
hudson/plugins/tasks/TasksProjectAction - should this be a separate Bug?

 random NoClassDefFoundError: 
 hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded
 -

 Key: JENKINS-12124
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12124
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Tomcat 6, JDK6, maven 3.0.3, SunOS, latest analysis* 
 plugins, latest jenkins
Reporter: Myron n/a
Priority: Minor

 It sometimes happens, that upon fresh start of tomcat, not all Jobs/Projects 
 are loaded.
 Once logging in and clicking on reload configuration from disk this works 
 w/o any error and all the missing jobs are there.
 It seems to be random... and on another restart some other jobs are missing...
 Any clue?
 {quote}
 INFO: Started all plugins
 Dec 16, 2011 9:14:36 AM jenkins.InitReactorRunner$1 onAttained
 INFO: Augmented all extensions
 Dec 16, 2011 9:14:59 AM jenkins.InitReactorRunner$1 onTaskFailed
 SEVERE: Failed Loading job XX
 java.lang.NoClassDefFoundError: 
 hudson/plugins/analysis/core/AbstractProjectAction
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
 at 
 hudson.plugins.checkstyle.CheckStylePublisher.getProjectAction(CheckStylePublisher.java:128)
 at 
 hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
 at hudson.model.Project.createTransientActions(Project.java:208)
 at 
 hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:602)
 at hudson.model.AbstractProject.onLoad(AbstractProject.java:272)
 at hudson.model.Project.onLoad(Project.java:88)
 at hudson.model.Items.load(Items.java:115)
 at jenkins.model.Jenkins$14.run(Jenkins.java:2364)
 at 
 org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
 at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
 at jenkins.model.Jenkins$5.runTask(Jenkins.java:804)
 at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
 at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.ClassNotFoundException: 
 hudson.plugins.analysis.core.AbstractProjectAction
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
 ... 27 more
 Dec 16, 2011 9:15:19 AM jenkins.InitReactorRunner$1 onAttained
 INFO: Loaded all jobs
 Dec 16, 2011 9:15:19 AM jenkins.InitReactorRunner$1 onAttained
 INFO: Completed initialization
 {quote}

--
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-12124) random NoClassDefFoundError: hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded


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

Myron n/a edited comment on JENKINS-12124 at 3/19/12 2:03 PM:
--

what exception are you now observing?
For me, with actual Jenkins 1.455 (as WAR) the java.lang.NoClassDefFoundError: 
hudson/plugins/analysis/core/AbstractProjectAction is gone (thanks Ulli).

Unfortunately, i'm now also seeing the java.lang.NoClassDefFoundError: 
hudson/plugins/tasks/TasksProjectAction - should this be a separate Bug?

Edit:
After several restarts, i now only have 10 jobs activated :( (from 70)
now i get more and more 
{quote}
java.lang.NoClassDefFoundError: hudson/plugins/warnings/WarningsProjectAction
at 
hudson.plugins.warnings.WarningsPublisher.getProjectAction(WarningsPublisher.java:229)
at 
hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
at 
hudson.maven.MavenModuleSet.createTransientActions(MavenModuleSet.java:355)
at 
hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:603)
at 
hudson.maven.MavenModuleSet.updateTransientActions(MavenModuleSet.java:342)
at hudson.model.AbstractProject.onLoad(AbstractProject.java:273)
at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:617)
at hudson.model.Items.load(Items.java:115)
at jenkins.model.Jenkins$15.run(Jenkins.java:2421)
at 
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$6.runTask(Jenkins.java:840)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
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)
Mar 19, 2012 3:01:20 PM jenkins.InitReactorRunner$1 onTaskFailed
{quote}
how can this be THAT random?

  was (Author: myron):
what exception are you now observing?
For me, with actual Jenkins 1.455 (as WAR) the java.lang.NoClassDefFoundError: 
hudson/plugins/analysis/core/AbstractProjectAction is gone (thanks Ulli).

Unfortunately, i'm now also seeing the java.lang.NoClassDefFoundError: 
hudson/plugins/tasks/TasksProjectAction - should this be a separate Bug?
  
 random NoClassDefFoundError: 
 hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded
 -

 Key: JENKINS-12124
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12124
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Tomcat 6, JDK6, maven 3.0.3, SunOS, latest analysis* 
 plugins, latest jenkins
Reporter: Myron n/a
Priority: Minor

 It sometimes happens, that upon fresh start of tomcat, not all Jobs/Projects 
 are loaded.
 Once logging in and clicking on reload configuration from disk this works 
 w/o any error and all the missing jobs are there.
 It seems to be random... and on another restart some other jobs are missing...
 Any clue?
 {quote}
 INFO: Started all plugins
 Dec 16, 2011 9:14:36 AM jenkins.InitReactorRunner$1 onAttained
 INFO: Augmented all extensions
 Dec 16, 2011 9:14:59 AM jenkins.InitReactorRunner$1 onTaskFailed
 SEVERE: Failed Loading job XX
 java.lang.NoClassDefFoundError: 
 hudson/plugins/analysis/core/AbstractProjectAction
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
 at 
 hudson.plugins.checkstyle.CheckStylePublisher.getProjectAction(CheckStylePublisher.java:128)
 at 
 hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
 at hudson.model.Project.createTransientActions(Project.java:208)
 at

[JIRA] (JENKINS-12124) random NoClassDefFoundError: hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded

2012-03-19 Thread sebastien.heurtema...@gmail.com (JIRA)


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

Myron n/a edited comment on JENKINS-12124 at 3/19/12 2:33 PM:
--

what exception are you now observing?
For me, with actual Jenkins 1.455 (as WAR) the java.lang.NoClassDefFoundError: 
hudson/plugins/analysis/core/AbstractProjectAction is gone (thanks Ulli).

Unfortunately, i'm now also seeing the java.lang.NoClassDefFoundError: 
hudson/plugins/tasks/TasksProjectAction - should this be a separate Bug?

Edit:
After several restarts, i now only have 10 jobs activated :( (from 70)
now i get more and more 
{quote}
java.lang.NoClassDefFoundError: hudson/plugins/warnings/WarningsProjectAction
at 
hudson.plugins.warnings.WarningsPublisher.getProjectAction(WarningsPublisher.java:229)
at 
hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
at 
hudson.maven.MavenModuleSet.createTransientActions(MavenModuleSet.java:355)
at 
hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:603)
at 
hudson.maven.MavenModuleSet.updateTransientActions(MavenModuleSet.java:342)
at hudson.model.AbstractProject.onLoad(AbstractProject.java:273)
at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:617)
at hudson.model.Items.load(Items.java:115)
at jenkins.model.Jenkins$15.run(Jenkins.java:2421)
at 
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$6.runTask(Jenkins.java:840)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
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)
Mar 19, 2012 3:01:20 PM jenkins.InitReactorRunner$1 onTaskFailed
{quote}
how can this be THAT random?


Edit2:
seems do have disappeared magically when upgrading to latest MavenCorePlugin + 
and latest FindBugs plugin...?!

  was (Author: myron):
what exception are you now observing?
For me, with actual Jenkins 1.455 (as WAR) the java.lang.NoClassDefFoundError: 
hudson/plugins/analysis/core/AbstractProjectAction is gone (thanks Ulli).

Unfortunately, i'm now also seeing the java.lang.NoClassDefFoundError: 
hudson/plugins/tasks/TasksProjectAction - should this be a separate Bug?

Edit:
After several restarts, i now only have 10 jobs activated :( (from 70)
now i get more and more 
{quote}
java.lang.NoClassDefFoundError: hudson/plugins/warnings/WarningsProjectAction
at 
hudson.plugins.warnings.WarningsPublisher.getProjectAction(WarningsPublisher.java:229)
at 
hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
at 
hudson.maven.MavenModuleSet.createTransientActions(MavenModuleSet.java:355)
at 
hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:603)
at 
hudson.maven.MavenModuleSet.updateTransientActions(MavenModuleSet.java:342)
at hudson.model.AbstractProject.onLoad(AbstractProject.java:273)
at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:617)
at hudson.model.Items.load(Items.java:115)
at jenkins.model.Jenkins$15.run(Jenkins.java:2421)
at 
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$6.runTask(Jenkins.java:840)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
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)
Mar 19, 2012 3:01:20 PM jenkins.InitReactorRunner$1 onTaskFailed
{quote}
how can this be THAT random?
  
 random NoClassDefFoundError: 
 hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded
 -

 Key: JENKINS-12124
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12124
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Tomcat 6, JDK6, maven 3.0.3, SunOS, latest analysis* 
 plugins, latest jenkins
Reporter: Myron n/a
Priority: Minor

 It

[JIRA] (JENKINS-13137) Job build does not fail on failed SVN update

2012-03-19 Thread nuabara...@web.de (JIRA)

Christoph Jaehnigen created JENKINS-13137:
-

 Summary: Job build does not fail on failed SVN update
 Key: JENKINS-13137
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13137
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Jenkins 1.455, Subversion plugin 1.39, Subversion 1.6
Reporter: Christoph Jaehnigen


When a job is executed and one of the SVN repositories has invalid credentials 
set (and thus the SVN update fails) this does not fail the build!

Updating https://stripped
ERROR: Failed to update https://stripped
org.tmatesoft.svn.core.SVNException: svn: OPTIONS /stripped failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)
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:1011)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:788)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:769)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2099)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /stripped failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
... 27 more
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS 
request failed on '/stripped'
svn: OPTIONS of /stripped: 403 Forbidden (https://stripped)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:656)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
... 26 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed 
on '/stripped'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366)
... 28 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /stripped: 
403 Forbidden (https://stripped)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:444)
at

[JIRA] (JENKINS-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)

2012-03-19 Thread gray...@gmail.com (JIRA)


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

Alex Gray updated JENKINS-13136:


Environment: 
Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
Slave Node: Windows XP
EnvInject: 1.38

  was:
Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
Slave Node: Windows XP
EnvInject: 1.36


 Environment Variable Injection injecting (and overriding) unwanted variables 
 (ie JAVA_HOME)
 ---

 Key: JENKINS-13136
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13136
 Project: Jenkins
  Issue Type: Bug
  Components: envinject
Affects Versions: current
 Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
 Slave Node: Windows XP
 EnvInject: 1.38
Reporter: Alex Gray
Assignee: gbois

 We were using EnvInject 1.35 in various free-style jobs, but after we 
 upgraded to 1.36 jobs started failing.
 This is the reason:
 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is 
 pointing to version 1.25.  I can verify this by going to Jenkins-Manage 
 Jenkins-Manage Nodes-MyWinXPNode-view log, and sure enough the node's 
 environment variables have JAVA_HOME pointing to 1.25
 2) After upgraded to EnvInject 1.36, the jobs started failing because 
 JAVA_HOME has been overwritten to 1.27, which does not exist on the node.  In 
 fact, I don't know where this is being set because the master does not have 
 java 1.27 either!
 The only option that is is present in the job is this:
 Inject environment variables to the build process
 Properties Content:
 TEMP=c:\\windows\\temp
 TMP=c:\\windows\\temp
 (everything else under Inject Environment Variables is blank.
 I have not tried the latest version, 1.38, but I will, since all the jobs are 
 currently broken and I have nothing else to lose...
 If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but 
 that does not work on multiconfiguration jobs.
 I'll keep you posted.  If this is fixed in 1.38, I will update this Jira.

--
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-10520) clone-workspace-scm performance is poor

2012-03-19 Thread ed.rand...@ingenotech.com (JIRA)

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

Ed Randall commented on JENKINS-10520:
--

This is our build pipeline:

1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.

2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.

3) Quick test - runs a relatively short test suite.

2a) Zip is promoted if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).

Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:

a) Only the latest workspace from step(1) is maintained. So if another change
triggers a Compile whilst Zip is in progress, it could be that (3) Quick test
actually tests that subsequent build and not the one it is supposed to be
testing. This has regularly caused us considerable confusion as the jobs were
out-of-step.

b) It takes so long ... our project is somewhat monolithic, including all
binaries required within the workspace. The workspace.zip archive is about
1.5Gb and creating it takes around 50 minutes using clone-workspace-plugin vs.
only 10 minutes for the actual compile, that's unacceptable. Un-zipping at the
start of the steps (2) and (3) is not quite so bad but still 10-20 minutes. It
seems to be something to do with the way data is piped between master and slave.

The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at the end of job (1) and
2 minutes at to un-archive it at the start of the other steps. It is attached
to this reportb for reference, to illustrate our use case which we would like
this plugin to support.

Use the script as follows:

At the end of job (1) invoke the script using Execute Shell:

${JENKINS_BIN}/clone-workspace PACK ${BUILD_TAG}

Optional INCLUDE= and EXCLUDE= filters can be used to limit the contents of the
archive. We actually create 2 archives, one is much smaller containing just
the information required for the promote step (2a) to work.

Also add a Post-Build action Trigger parameterized build on other projects to
start job (2) using the parameter:

UPSTREAM_BUILD_TAG=${BUILD_TAG}

Jobs (2) and (3) are parameterized, accepting UPSTREAM_BUILD_TAG. The first
task that each of these downstream jobs runs is:

Execute Shell

${JENKINS_BIN}/clone-workspace UNPACK ${UPSTREAM_BUILD_TAG}

The archive dir must exist on the master node and be referenced by the
JOBS_ARCHIVE environment variable.
The last job in the pipeline removes the redundant archive by invoking:

${JENKINS_BIN}/clone-workspace CLEAN ${UPSTREAM_BUILD_TAG}

We also purge all archives from it overnight using a cron job, just to be
sure.

Now the downstream jobs don't show the change history; that was solved by
re-instating the clone-workspace-plugin but configured to archive just one file.

clone-workspace-scm performance is poor
---

Key: JENKINS-10520
URL: https://issues.jenkins-ci.org/browse/JENKINS-10520
Project: Jenkins
Issue Type: Improvement
Components: clone-workspace
Affects Versions: current
Environment: Solaris/x86, cluster of 5 nodes, all machines in cluster
are identical
Reporter: Ed Randall
Assignee: abayer
Attachments: clone-workspace

Clone workspace performance is poor. Whilst compilation takes around 4
minutes, archiving the workspace afterwards takes the total job time out to
35 minutes! Similarly un-archiving it at the start of downstream jobs.
We have 4 steps, Compile, quick test, package, full test.
Compile uses Perforce SCM, we use clone workspace after that to ensure
downstream builds use identical files but other compiles can continue in
parallel. So we need almost the files in the entire workspace.
The filesystem workspace size is about 1.6Gb
The archived workspace.zip file size is about 1.4Gb
An exclude filter may help a little but I think there is something slow
going on.
Note that we use slaves as well so the piped data may have an impact, but all
the machines are very close together.
When the compile runs on the master node it doesn't seem any quicker.

[JIRA] (JENKINS-10520) clone-workspace-scm performance is poor

2012-03-19 Thread ed.rand...@ingenotech.com (JIRA)

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

Ed Randall edited comment on JENKINS-10520 at 3/19/12 3:40 PM:
---

This is our build pipeline:

1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.

2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.

3) Quick test - runs a relatively short test suite.

2a) Zip is promoted if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).

Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:

The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at the end of job (1) and
2 minutes at to un-archive it at the start of the other steps. It is attached
to this report to illustrate our use case which we would like this plugin to
support.

Use the script as follows:

At the end of job (1) invoke the script using Execute Shell:

${JENKINS_BIN}/clone-workspace PACK ${BUILD_TAG}

Also add a Post-Build action Trigger parameterized build on other projects to
start job (2) using the parameter:

UPSTREAM_BUILD_TAG=${BUILD_TAG}

Jobs (2) and (3) are parameterized, accepting UPSTREAM_BUILD_TAG. The first
task that each of these downstream jobs runs is:

Execute Shell

${JENKINS_BIN}/clone-workspace UNPACK ${UPSTREAM_BUILD_TAG}

The archive dir must exist on the master node and be referenced by the
JOBS_ARCHIVE environment variable.
The last job in the pipeline removes the redundant archive by invoking:

${JENKINS_BIN}/clone-workspace CLEAN ${UPSTREAM_BUILD_TAG}

We also purge all archives from it overnight using a cron job, just to be
sure.

Now the downstream jobs don't show the change history; that was solved by
re-instating the clone-workspace-plugin but configured to archive just one file.

was (Author: edrandall):
This is our build pipeline:

1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.

2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.

3) Quick test - runs a relatively short test suite.

2a) Zip is promoted if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).

Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:

The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at the end of job (1)

[JIRA] (JENKINS-7444) Distributed builds: Scheduling strategy

2012-03-19 Thread ed.rand...@ingenotech.com (JIRA)

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

Ed Randall commented on JENKINS-7444:
-

+1 for this.
We have 4 slaves, all identical, all the same network distance from the master.
Each slave is configured to have 2 executors.
We've noticed that Jenkins always seems to favour one slave in particular, to
the extent that it will run 2 jobs on it simultaneously even when all the other
slaves are idle.
This is not ideal so I reduced the executors on that node to 1. Now it does
the same behaviour, but preferring a different node.
I'd prefer if it took account of the current job situation (or recent average
CPU load?) when allocating a new job as well.

Distributed builds: Scheduling strategy
---

Key: JENKINS-7444
URL: https://issues.jenkins-ci.org/browse/JENKINS-7444
Project: Jenkins
Issue Type: Improvement
Components: master-slave
Affects Versions: current
Reporter: dbubovych
Priority: Minor
Fix For: current

It would be nice if Hudson could schedule build to the most free node, rather
then to the node where last build was taken.
For ex. I have projects A, B, C... configured with roam=true and nodes
Node1 and Node2 (number of jobs then number of runners at one node). Last
build for A and B was made on Node1, because all executors were busy. Then,
if I force build for A and B at the same time, they will build together on
Node1, even if Node2 currently do not run any builds. So, build will finish
much faster if A would be scheduled to Node1 and B to Node2, or any other
free Node.

[JIRA] (JENKINS-13139) User Name and Password are necessary only for verify action

Sébastien Heurtematte created JENKINS-13139:
---

 Summary: User Name and Password are necessary only for verify 
action
 Key: JENKINS-13139
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13139
 Project: Jenkins
  Issue Type: Improvement
  Components: mantis
Affects Versions: current
 Environment: Debian  x64
Reporter: Sébastien Heurtematte
Assignee: sogabe
Priority: Minor
 Fix For: current


In my case, I want to force user login only in project job and not use 
credencial from jenkins main configuration. 
Maybe, it's not necessary to put required label on UserName et password 
fields.
But only, requiered label on verify action.


--
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-13139) User Name and Password are necessary only for verify action

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


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

sogabe commented on JENKINS-13139:
--

 I want to force user login only in project job and not use credencial from 
 jenkins main configuration. 

I do not see what you say. 
Credential is mandatory to update mantis ticket and you can only enter it in 
main configuration. 

 User Name and Password are necessary only for verify action
 -

 Key: JENKINS-13139
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13139
 Project: Jenkins
  Issue Type: Improvement
  Components: mantis
Affects Versions: current
 Environment: Debian  x64
Reporter: Sébastien Heurtematte
Assignee: sogabe
Priority: Minor
  Labels: mantis, requiered
 Fix For: current


 In my case, I want to force user login only in project job and not use 
 credencial from jenkins main configuration. 
 Maybe, it's not necessary to put required label on UserName et password 
 fields.
 But only, requiered label on verify action.

--
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-12982) Run conditions should be passed Launcher object

2012-03-19 Thread cjo9...@java.net (JIRA)


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

cjo9900 commented on JENKINS-12982:
---

Having looked at the code in more places I see that there are several places 
that do not have a launcher present in the first place, i.e 
Dependency.shouldTriggerBuild(AbstractBuild build, TaskListener listener, 
ListAction actions), Prebuild(AbstractBuild build, TaskListener listener)

However I think that a launcher can be created within the condition using the 
following

runPerform(final AbstractBuild?, ? build, final BuildListener listener) 
throws Exception;
{
Launcher launcher = build.getWorkspace().createLauncher(listener);
/* some action here */
}

This is untried code, but is a better alternative than altering all of the 
existing uses.

If this is a usable solution close the issue.


http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html
http://javadoc.jenkins-ci.org/hudson/FilePath.html#createLauncher(hudson.model.TaskListener)


 Run conditions should be passed Launcher object
 ---

 Key: JENKINS-12982
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12982
 Project: Jenkins
  Issue Type: Improvement
  Components: run-condition
Reporter: cjo9900
Assignee: bap

 Run conditions should be passed Launcher object so that the conditions may be 
 allowed to run scripts within the build, e.g call a Shell or groovy script.
 Current implementations are 
 public abstract boolean runPrebuild(final AbstractBuild?, ? build, final 
 BuildListener listener) throws Exception;
 public abstract boolean runPerform(final AbstractBuild?, ? build, final 
 BuildListener listener) throws Exception;
 These should be extended to 
 (final AbstractBuild?, ? build, final BuildListener listener, final 
 Launcher launcher) 

--
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-13140) Disconnected slaves come back online within a few minutes

2012-03-19 Thread norman.baum...@gmail.com (JIRA)

Norman Baumann created JENKINS-13140:


 Summary: Disconnected slaves come back online within a few minutes
 Key: JENKINS-13140
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13140
 Project: Jenkins
  Issue Type: Bug
  Components: slave-setup
Affects Versions: current
 Environment: Linux Jenkins Master and build slave
Reporter: Norman Baumann
Assignee: Kohsuke Kawaguchi


I have a Jenkins installation with 20 build slaves. A couple of minutes after I 
click on Disconnect slave, the slave is back online.

The log contains:

Mar 19, 2012 5:22:19 PM hudson.slaves.SlaveComputer tryReconnect
INFO: Attempting to reconnect musxdodo77

Somehow Jenkins is ignoring the offline tag when set manually.

--
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-13139) User Name and Password are necessary only for verify action

2012-03-19 Thread sebastien.heurtema...@gmail.com (JIRA)


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

Sébastien Heurtematte commented on JENKINS-13139:
-

OK
It's a mistake, seen from this angle.


 User Name and Password are necessary only for verify action
 -

 Key: JENKINS-13139
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13139
 Project: Jenkins
  Issue Type: Improvement
  Components: mantis
Affects Versions: current
 Environment: Debian  x64
Reporter: Sébastien Heurtematte
Assignee: sogabe
Priority: Minor
  Labels: mantis, requiered
 Fix For: current


 In my case, I want to force user login only in project job and not use 
 credencial from jenkins main configuration. 
 Maybe, it's not necessary to put required label on UserName et password 
 fields.
 But only, requiered label on verify action.

--
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-13139) User Name and Password are necessary only for verify action

2012-03-19 Thread sebastien.heurtema...@gmail.com (JIRA)


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

Sébastien Heurtematte resolved JENKINS-13139.
-

Resolution: Not A Defect

 User Name and Password are necessary only for verify action
 -

 Key: JENKINS-13139
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13139
 Project: Jenkins
  Issue Type: Improvement
  Components: mantis
Affects Versions: current
 Environment: Debian  x64
Reporter: Sébastien Heurtematte
Assignee: sogabe
Priority: Minor
  Labels: mantis, requiered
 Fix For: current


 In my case, I want to force user login only in project job and not use 
 credencial from jenkins main configuration. 
 Maybe, it's not necessary to put required label on UserName et password 
 fields.
 But only, requiered label on verify action.

--
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-4744) Can't delete dead ec2-generated nodes

2012-03-19 Thread fran...@oaklandsoftware.com (JIRA)


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

francis Upton commented on JENKINS-4744:


@Baskaran, I don't know; this is a more generic Jenkins question. Perhaps you 
can ask on the email list or in the IRC channel.

 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-13138) Verify action doesn't work with CSRF option

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


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

sogabe commented on JENKINS-13138:
--

I can not reproduce it.
Let me know how to reporoduce?

 Verify action doesn't work with CSRF option
 ---

 Key: JENKINS-13138
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13138
 Project: Jenkins
  Issue Type: Bug
  Components: mantis
Affects Versions: current
 Environment: Debian x64
Reporter: Sébastien Heurtematte
Assignee: sogabe
Priority: Minor
  Labels: csrf, mantis
 Attachments: mantis.jpg


 Etat HTTP 403 - No valid crumb was included in the request

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

[JIRA] (JENKINS-13141) Extended Choice Parameter does not work with Rebuild plugin

2012-03-19 Thread y...@schli.ch (JIRA)

Marc Günther created JENKINS-13141:
--

 Summary: Extended Choice Parameter does not work with Rebuild 
plugin
 Key: JENKINS-13141
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13141
 Project: Jenkins
  Issue Type: Bug
  Components: extended-choice-parameter
Reporter: Marc Günther
Priority: Minor




Status Code: 500

Exception: 
Stacktrace:
org.apache.commons.jelly.JellyTagException: 
file:/var/lib/jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/index.jelly:54:63:
 st:include No page found 'ExtendedChoiceParameterValue.jelly' for class 
com.sonyericsson.rebuild.RebuildAction
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53)
at 
org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107)
at 
org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:552)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at

[JIRA] (JENKINS-13141) Extended Choice Parameter does not work with Rebuild plugin

2012-03-19 Thread y...@schli.ch (JIRA)


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

Marc Günther updated JENKINS-13141:
---

Description: 
{code}
Status Code: 500

Exception: 
Stacktrace:
org.apache.commons.jelly.JellyTagException: 
file:/var/lib/jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/index.jelly:54:63:
 st:include No page found 'ExtendedChoiceParameterValue.jelly' for class 
com.sonyericsson.rebuild.RebuildAction
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53)
at 
org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107)
at 
org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:552)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)

[JIRA] (JENKINS-13141) Extended Choice Parameter does not work with Rebuild plugin

2012-03-19 Thread y...@schli.ch (JIRA)


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

Marc Günther updated JENKINS-13141:
---

Description: 
When clicking on Rebuild in a project which uses an ECP, I get this 
stacktrace:
{code}
Status Code: 500

Exception: 
Stacktrace:
org.apache.commons.jelly.JellyTagException: 
file:/var/lib/jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/index.jelly:54:63:
 st:include No page found 'ExtendedChoiceParameterValue.jelly' for class 
com.sonyericsson.rebuild.RebuildAction
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63)
at 
org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53)
at 
org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107)
at 
org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:552)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at

[JIRA] (JENKINS-7830) using environment variable for local port of ssh tunnel

2012-03-19 Thread l...@lorrin.org (JIRA)


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

Lorrin Nelson commented on JENKINS-7830:


I would appreciate this too. I would like to use the Sauce OnDemand plug-in 
with the Port Allocator plug-in.

 using environment variable for local port of ssh tunnel
 ---

 Key: JENKINS-7830
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7830
 Project: Jenkins
  Issue Type: New Feature
  Components: sauce-ondemand
Reporter: scytacki
Assignee: Ross Rowe

 I use an environment variable to set the port used by the local server that I 
 want to test.  I do this because we want to be able to build/test the hudson 
 job on multiple slave nodes at the same time.  We currently have those slave 
 nodes running on the same machine. If the port is hard coded then I can't 
 startup multiple local servers at the same time because the port will be the 
 same for each and will conflict.
 So it would be helpful if the sauce-ondemand plugin would allow using 
 environment variables for the Local Port setting.

--
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-12048) Wrong option --branch used by change polling

2012-03-19 Thread emidiost...@gmail.com (JIRA)


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

Emidio Stani commented on JENKINS-12048:


I just want to confirm what Cass Costello said, pulling the snapshot from the 
repository and installing the hpi works.

 Wrong option --branch used by change polling 
 ---

 Key: JENKINS-12048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12048
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Reporter: Christoph Neuroth
Assignee: davidmc24
Priority: Critical

 With Jenkins 1.442, Mercurial Plugin 1.38, the change polling issues a hg 
 log command using \-\-branch foo, which mercurial doesn't know about. 
 Should be \-b or \-\-only-branch.

--
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-12048) Wrong option --branch used by change polling

2012-03-19 Thread emidiost...@gmail.com (JIRA)


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

Emidio Stani resolved JENKINS-12048.


Resolution: Fixed

Version 1.39 Snapshot solved the issue

 Wrong option --branch used by change polling 
 ---

 Key: JENKINS-12048
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12048
 Project: Jenkins
  Issue Type: Bug
  Components: mercurial
Reporter: Christoph Neuroth
Assignee: davidmc24
Priority: Critical

 With Jenkins 1.442, Mercurial Plugin 1.38, the change polling issues a hg 
 log command using \-\-branch foo, which mercurial doesn't know about. 
 Should be \-b or \-\-only-branch.

--
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-13142) launch the app after installing

2012-03-19 Thread jus...@saturnboy.com (JIRA)

Justin Shacklette created JENKINS-13142:
---

 Summary: launch the app after installing
 Key: JENKINS-13142
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13142
 Project: Jenkins
  Issue Type: New Feature
  Components: android-emulator
Reporter: Justin Shacklette
Assignee: Christopher Orr
Priority: Minor


The Android Emulator plugin lets you install the APK, but not launch it.

It'd be awesome if you could also launch the installed APK. Maybe another 
checkbox alongside the existing Uninstall existing APK first checkbox that 
says Launch after installing APK

It's easy to launch an app with adb:
adb shell am start -n com.package.name/com.package.name.ActivityName

This feature would be great because some automated testing usecases require the 
app to be running.

--
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-19 Thread michael.m.cla...@gmail.com (JIRA)


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

Michael Clarke reopened JENKINS-12582:
--

  Assignee: Michael Clarke  (was: Alex Lehmann)

Reopening as the main issue (having to specify a password for every job) still 
needs resolved.

 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: Michael Clarke
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-11576) Getting returned status code 128: ssh_exchange_identification error sometimes

2012-03-19 Thread maxime.petazz...@turn.com (JIRA)


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

Maxime Petazzoni commented on JENKINS-11576:


Hi all,

I am experiencing the same issue and it seems very random. I can't pinpoint 
what is going on. It only fails when the job is set to run on a schedule 
(regardless of schedule/time of trigger) and the rate of failure seems random.

One thing that is interesting is that asking to wipe out the workspace before 
each build fixes the issue, meaning that the git clone works without issues, 
but for some reason the git fetch done after that when the workspace isn't 
cleaned sometimes fails.

What I don't understand is that for other jobs using SCM polling, Jenkins also 
does a git fetch but it always works (from the exact same Git repository).

So right now wiping out the workspace is a workaround, but it might not be 
suitable for everybody.

 Getting returned status code 128: ssh_exchange_identification error 
 sometimes
 ---

 Key: JENKINS-11576
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11576
 Project: Jenkins
  Issue Type: Bug
  Components: git
Affects Versions: current
 Environment: Windows Server 2003, IIS
Reporter: Murali Srinivasan
Priority: Blocker
  Labels: exception, git, jenkins, ssh_exchange_identification

 I have Jenkins setup in Windows Server machine and the job will trigger the 
 build at specified time. Sometimes the job fails with the below exception and 
 when I manually trigger it again it will work fine. I read somewhere that 
 moving id_rsa.* file to GIT installation folder will fix the issue, but it 
 didn't improve in my case. It would be great if there is a way to fix this 
 issue.
 ERROR: Problem fetching from origin / origin - could be unavailable. 
 Continuing anyway
 ERROR:  (Underlying report) : Error performing command: E:\git\bin\git.exe 
 fetch -t gitosis@..com:ServiceApp +refs/heads/*:refs/remotes/origin/*
 Command E:\git\bin\git.exe fetch -t gitosis@..com:ServiceApp 
 +refs/heads/*:refs/remotes/origin/* returned status code 128: 
 ssh_exchange_identification: Connection closed by remote host
 fatal: The remote end hung up unexpectedly
 ERROR: Could not fetch from any repository
 FATAL: Could not fetch from any repository
 hudson.plugins.git.GitException: Could not fetch from any repository
   at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1008)
   at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:968)
   at hudson.FilePath.act(FilePath.java:785)
   at hudson.FilePath.act(FilePath.java:767)
   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:968)
   at hudson.model.AbstractProject.checkout(AbstractProject.java:1193)
   at 
 hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:567)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:455)
   at hudson.model.Run.run(Run.java:1404)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:230)

--
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-19 Thread alexl...@gmail.com (JIRA)


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

Alex Lehmann commented on JENKINS-12582:


sorry, you're right, I missed the part about setting the cvs password for each 
job, changed the changelog entry accordingly


 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: Michael Clarke
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-13143) Can't connect on host using a port greater than 999

2012-03-19 Thread fcamb...@java.net (JIRA)

fcamblor created JENKINS-13143:
--

 Summary: Can't connect on host using a port greater than 999
 Key: JENKINS-13143
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13143
 Project: Jenkins
  Issue Type: Bug
  Components: publish-over-ssh
Reporter: fcamblor
Assignee: bap
Priority: Critical


I configured publish-over-ssh plugin (v1.6) on my current jenkins, with port 
2232, and it fails to connect.

Using port 22 (on another host) works fine though.

When I use verbose mode on the plugin, I have :
SSH: Connecting from host [jenkins-slave-ubuntu3]
SSH: Connecting with configuration [XXX nightly] ...
SSH: Creating session: username [xxx], hostname [X.X.X.X], port [2,232]
SSH: Connecting session ...
ERROR: Exception when publishing, exception message [Failed to connect session 
for config [XXX nightly]. Message [java.net.ConnectException: Connection 
refused]]

I think the 2,232 is the cause of the 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-11248) Build fails on Deploy artifacts to Maven repository due to trying to upload parent POM twice for release artifacts

2012-03-19 Thread mrasmus...@luthresearch.com (JIRA)


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

Michael Rasmussen commented on JENKINS-11248:
-

[~outro] No, we were not trying to deploy snapshots to our releases repository. 
We have both http://hostname/nexus/content/repositories/*releases*/ and 
http://hostname/nexus/content/repositories/*snapshots*/ properly defined in 
our POMs for deploying.

Anyway, there was a fix released for this in 1.449. We are still on 1.447, so I 
haven't had a chance to confirm and close the bug.

 Build fails on Deploy artifacts to Maven repository due to trying to upload 
 parent POM twice for release artifacts
 

 Key: JENKINS-11248
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11248
 Project: Jenkins
  Issue Type: Bug
  Components: deploy, maven2
Affects Versions: current
 Environment: OS: CentOS release 5.5 (Final)
 Jenkins: 1.433
 Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+)
 Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-194.32.1.el5, arch: amd64, family: 
 unix
Reporter: Michael Rasmussen
Assignee: olamy

 Scenario: We have several sets of Java OSGi services with a parent pom and 4 
 child projects/poms. The parent pom does not generate any JARs, but each of 
 the children generates a jar.Something like the following:
 {noformat}
 project_folder/
   |_servicename.business/
   |   \_pom.xml
   |_servicename.jms/
   |   \_pom.xml
   |_servicename.model/
   |   \_pom.xml
   |_servicename.webservice/
   |   \_pom.xml
   \_pom.xml
 {noformat} 
 Each of these services is setup as a separate Jenkins job, and the maven 
 dependencies are turned on so they all build in the appropriate order.
 Within the parent pom we have our distributionManagement section defined so 
 we can run the mvn deploy goals to upload artifacts to our maven repository.
 Up until this point we have only been building SNAPSHOTS, for which the Nexus 
 repository allows redeploying of artifacts.
 WHAT IS GOING WRONG:
 The other day we tried to build our first release version of some of the 
 services, and the deployment into the Nexus maven repository failed on the 
 Deploy artifacts to Maven repository task.
 Looking at the Console Output of the failed job, for some reason Jenkins is 
 trying to deploy the parent POM a second time. Nexus refuses this, as it does 
 not allow redeploying of release artifacts. Below is an excerpt from the 
 output of one of those jobs:
 {quote}
 [INFO] 
 
 [INFO] BUILD SUCCESS
 [INFO] 
 
 [INFO] Total time: 52.240s
 [INFO] Finished at: Thu Oct 06 14:55:37 GMT 2011
 [INFO] Final Memory: 63M/151M
 [INFO] 
 
 channel stopped
 Maven RedeployPublished use remote  maven settings from : 
 /opt/maven/conf/settings.xml
 [ERROR] uniqueVersion == false is not anymore supported in maven 3
 [INFO] Deployment in 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/ 
 (id=com.luthresearch,uniqueVersion=false)
 Deploying the main artifact savvyconnect-1.0.1.pom
 Uploading: 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
 Uploaded: 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
  (3 KB at 24.4 KB/sec)
 Uploading: 
 http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
 ERROR: Failed to deploy artifacts: Could not transfer artifact 
 com.luthresearch.savvyconnect:savvyconnect:pom:1.0.1 from/to com.luthresearch 
 (dav:http://maven.luthresearch.net/nexus/content/repositories/releases/): 
 Failed to transfer file: 
 http://maven.luthresearch.net/nexus/content/repositories/releases//com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom.
  Return code is: 400
 org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
 deploy artifacts: Could not transfer artifact 
 com.luthresearch.savvyconnect:savvyconnect:pom:1.0.1 from/to com.luthresearch 
 (dav:http://maven.luthresearch.net/nexus/content/repositories/releases/): 
 Failed to transfer file: 
 http://maven.luthresearch.net/nexus/content/repositories/releases//com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom.
  Return code is: 400
   at

[JIRA] (JENKINS-13144) platformlabeler link in Manage Plugins goes to hudson-ci.org wiki

2012-03-19 Thread docw...@gerf.org (JIRA)

Christian Höltje created JENKINS-13144:
--

 Summary: platformlabeler link in Manage Plugins goes to 
hudson-ci.org wiki
 Key: JENKINS-13144
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13144
 Project: Jenkins
  Issue Type: Bug
  Components: platformlabeler
Reporter: Christian Höltje
Assignee: lifeless
Priority: Minor


If you go to Manage Jenkins - Manage Plugins and click on the link for Hudson 
platformlabeler plugin then it goes to 
http://wiki.hudson-ci.org/display/HUDSON/PlatformLabeler+Plugin

It should go to 
http://wiki.jenkins-ci.org/display/JENKINS/PlatformLabeler+Plugin

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

[JIRA] (JENKINS-13145) platformlabeler: Labels aren't recognized in expressions until a node is configured and saved.

2012-03-19 Thread docw...@gerf.org (JIRA)

Christian Höltje created JENKINS-13145:
--

 Summary: platformlabeler: Labels aren't recognized in  
expressions until a node is configured and saved.
 Key: JENKINS-13145
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13145
 Project: Jenkins
  Issue Type: Bug
  Components: platformlabeler
Affects Versions: current
 Environment: JRE 1.7
Reporter: Christian Höltje
Assignee: lifeless


The platformlabelers' labels don't seem to work until you go into a Node and 
configure it and save (you don't have to change anything).

To recreate:

* Install the plugin
* Create a job restricted to nodes with expression like 
CentOSfirefoxjruby (assuming you have a node like that)
* Restart Jenkins
* build the job

Notice how it says that no nodes exist for CentOSfirefoxjruby. You can 
click on it and it shows no nodes matching that.

To fix:
* Go to a node with CentOS as a label
* configure it
* save it (no changes needed)

Notice how the job finds the appropriate node.


--
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-19 Thread alexl...@gmail.com (JIRA)

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

Alex Lehmann updated JENKINS-13129:
---

Environment:
jenkins 1.456, tomcat 7.0.25, java 1.6.0-31 running on windows vista

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

Description:
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.

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

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

issue is still present in 1.456

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

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

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.

[JIRA] (JENKINS-6817) FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel

2012-03-19 Thread arah...@switchfly.com (JIRA)


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

Atiq Rahman commented on JENKINS-6817:
--

My slave machine was working just fine and suddenly I started to see this 
problem when trying to launch the service from slave. Any thoughts anyone

 FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 --

 Key: JENKINS-6817
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6817
 Project: Jenkins
  Issue Type: Bug
  Components: clone-workspace, core
Affects Versions: current
Reporter: nirmal_patel
Assignee: abayer
Priority: Blocker

 I am seeing the same on my Windows XP master-slave setup. I am running latest 
 Hudson ver. 1.363
 I am using the close-workspace-scm plugin to copy my workspace from master to 
 slave(150).
 Started by user anonymous
 Building remotely on 150
 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:137)
 at hudson.remoting.Channel.call(Channel.java:555)
 at hudson.FilePath.act(FilePath.java:742)
 at hudson.FilePath.act(FilePath.java:735)
 at hudson.FilePath.unzip(FilePath.java:415)
 at 
 hudson.FileSystemProvisioner$Default$WorkspaceSnapshotImpl.restoreTo(FileSystemProvisioner.java:227)
 at 
 hudson.plugins.cloneworkspace.CloneWorkspaceSCM$Snapshot.restoreTo(CloneWorkspaceSCM.java:344)
 at 
 hudson.plugins.cloneworkspace.CloneWorkspaceSCM.checkout(CloneWorkspaceSCM.java:126)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1044)
 at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
 at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
 at hudson.model.Run.run(Run.java:1253)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:127)
 Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 at hudson.remoting.Request.abort(Request.java:257)
 at hudson.remoting.Channel.terminate(Channel.java:602)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:893)
 Caused by: java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:875)
 Caused by: java.io.EOFException
 at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source)
 at java.io.ObjectInputStream.readObject0(Unknown Source)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:869)

--
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-19 Thread sku...@gcefederal.com (JIRA)

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

suresh kukalakuntla commented on JENKINS-13119:
---

Thank You so much Greg for your quick response, with a plugin update!!!

I installed EnvInject 1.38, added similar groovy script to my job and tried to
build it. I got the below error.

[EnvInject] - Preparing an environment for the build.
[EnvInject] - [ERROR] - SEVERE ERROR occurs:
com/sun/xml/internal/ws/server/UnsupportedMediaException

I think I have to add required jar to class path of JBOSS AS 7 I am using for
jenkins, which I do not know how to. I am trying to find out how to do that.
Could you please let me know how to do that, if you already know about it?

I will provide an update once I am able to successfully use the updated plugin
to set environment variables based on user input.

Thank You once again for your effort.

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

[JIRA] (JENKINS-11641) when Rakefile is not in the default location, Rake working directory setting does not work

2012-03-19 Thread dr.ec...@gmail.com (JIRA)


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

Steve Eckhardt commented on JENKINS-11641:
--

+1 on this issue.  I love the above description, and wish all my users were so 
good at stating the issue clearly.  Could the issue be upgraded from Minor?

 when Rakefile is not in the default location, Rake working directory 
 setting does not work
 

 Key: JENKINS-11641
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11641
 Project: Jenkins
  Issue Type: Bug
  Components: rake
Affects Versions: current
 Environment: Windows Server 2008 R2 Standard 64-bit
 Jenkins 1.437 (installed via native package for windows)
 Jenkins Rake plugin 1.7.7
 ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
 rake 0.9.2.2
Reporter: Željko Filipin
Assignee: david_calavera
Priority: Minor
  Labels: jenkins, plugin

 - create new free style project
 - in git repository there are Rakefiles in root folder (workspace/Rakefile) 
 and in spec folder (workspace/spec/Rakefile)
 - create Invoke Rake build step
 - click button Advanced for Rake
 - set Rake working directory to spec
 - Rakefile just outputs working directory, it looks like this:
 {code} 
 task :default do
   puts Dir.pwd
 end
 {code}
 - save changes
 - run build
 - console output is:
 {code}
 ...
 [spec] $ rake.bat
 C:/Jenkins/jobs/testjob/workspace/spec
 Finished: SUCCESS
 {code}
 - so far so good
 - go to configure build job screen and change Rake file to spec/Rakefile
 - save changes
 - run build
 - console output is:
 {code}
 ...
 [spec] $ rake.bat --rakefile spec/Rakefile
 (in C:/Jenkins/jobs/test/workspace)
 C:/Jenkins/jobs/testjob/workspace
 Finished: SUCCESS
 {code}
 - when Rakefile is not in the default location, Rake working directory 
 setting does not work

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

[JIRA] (JENKINS-13147) Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins with different cases in their path not to get excluded

2012-03-19 Thread pmacc...@yahoo.com (JIRA)

Patrick McKeown created JENKINS-13147:
-

 Summary: Perforce Plugin's Poll Exclude File(s) is case sensitive 
causing checkins with different cases in their path not to get excluded
 Key: JENKINS-13147
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13147
 Project: Jenkins
  Issue Type: Improvement
  Components: perforce
Affects Versions: current
Reporter: Patrick McKeown
Priority: Minor


Say I am excluding //depot/Branch/*

If someone checks in a file
//depot/Branch/test.txt
it will properly be exluded

but if they check in a file as 
//depot/branch/test.txt
the case difference will cause it to not be excluded.

The problem stems from the fact that you can add files to perforce with 
different cases because it is case insensitive.  

I would like the exclude list to be case insensitive as well, or at least add 
an option for it to be.  

Thanks for the awesome plugin!

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

[JIRA] (JENKINS-11641) when Rakefile is not in the default location, Rake working directory setting does not work

2012-03-19 Thread dr.ec...@gmail.com (JIRA)


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

Steve Eckhardt commented on JENKINS-11641:
--

blush I just figured out why this is minor.  If you use the standard name for 
the rake file and just set the working directory, it works.  In the above 
example, all the user would have had to do is leave Rakefile in the spec 
directory and set the working directory to spec.  It is not necessary to have 
the Rakefile in workspace.

 when Rakefile is not in the default location, Rake working directory 
 setting does not work
 

 Key: JENKINS-11641
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11641
 Project: Jenkins
  Issue Type: Bug
  Components: rake
Affects Versions: current
 Environment: Windows Server 2008 R2 Standard 64-bit
 Jenkins 1.437 (installed via native package for windows)
 Jenkins Rake plugin 1.7.7
 ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
 rake 0.9.2.2
Reporter: Željko Filipin
Assignee: david_calavera
Priority: Minor
  Labels: jenkins, plugin

 - create new free style project
 - in git repository there are Rakefiles in root folder (workspace/Rakefile) 
 and in spec folder (workspace/spec/Rakefile)
 - create Invoke Rake build step
 - click button Advanced for Rake
 - set Rake working directory to spec
 - Rakefile just outputs working directory, it looks like this:
 {code} 
 task :default do
   puts Dir.pwd
 end
 {code}
 - save changes
 - run build
 - console output is:
 {code}
 ...
 [spec] $ rake.bat
 C:/Jenkins/jobs/testjob/workspace/spec
 Finished: SUCCESS
 {code}
 - so far so good
 - go to configure build job screen and change Rake file to spec/Rakefile
 - save changes
 - run build
 - console output is:
 {code}
 ...
 [spec] $ rake.bat --rakefile spec/Rakefile
 (in C:/Jenkins/jobs/test/workspace)
 C:/Jenkins/jobs/testjob/workspace
 Finished: SUCCESS
 {code}
 - when Rakefile is not in the default location, Rake working directory 
 setting does not work

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

[JIRA] (JENKINS-6817) FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel

2012-03-19 Thread arah...@switchfly.com (JIRA)


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

Atiq Rahman edited comment on JENKINS-6817 at 3/19/12 9:17 PM:
---

My slave machine was working just fine and suddenly I started to see this 
problem when trying to launch the service from slave. Any thoughts anyone

I get this message

java.io.EOFException: unexpected stream termination
at hudson.remoting.Channel.init(Channel.java:408)
at hudson.remoting.Channel.init(Channel.java:366)
at hudson.remoting.Channel.init(Channel.java:327)
at hudson.remoting.Channel.init(Channel.java:323)
at hudson.remoting.Channel.init(Channel.java:311)
at hudson.remoting.Engine.run(Channel.java:238)

  was (Author: arahmanswitchfly):
My slave machine was working just fine and suddenly I started to see this 
problem when trying to launch the service from slave. Any thoughts anyone
  
 FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 --

 Key: JENKINS-6817
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6817
 Project: Jenkins
  Issue Type: Bug
  Components: clone-workspace, core
Affects Versions: current
Reporter: nirmal_patel
Assignee: abayer
Priority: Blocker

 I am seeing the same on my Windows XP master-slave setup. I am running latest 
 Hudson ver. 1.363
 I am using the close-workspace-scm plugin to copy my workspace from master to 
 slave(150).
 Started by user anonymous
 Building remotely on 150
 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:137)
 at hudson.remoting.Channel.call(Channel.java:555)
 at hudson.FilePath.act(FilePath.java:742)
 at hudson.FilePath.act(FilePath.java:735)
 at hudson.FilePath.unzip(FilePath.java:415)
 at 
 hudson.FileSystemProvisioner$Default$WorkspaceSnapshotImpl.restoreTo(FileSystemProvisioner.java:227)
 at 
 hudson.plugins.cloneworkspace.CloneWorkspaceSCM$Snapshot.restoreTo(CloneWorkspaceSCM.java:344)
 at 
 hudson.plugins.cloneworkspace.CloneWorkspaceSCM.checkout(CloneWorkspaceSCM.java:126)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1044)
 at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
 at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
 at hudson.model.Run.run(Run.java:1253)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:127)
 Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 at hudson.remoting.Request.abort(Request.java:257)
 at hudson.remoting.Channel.terminate(Channel.java:602)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:893)
 Caused by: java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:875)
 Caused by: java.io.EOFException
 at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source)
 at java.io.ObjectInputStream.readObject0(Unknown Source)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:869)

--
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-13148) Quick Search should include disabled jobs in is corpus

2012-03-19 Thread carl.qu...@gmail.com (JIRA)

Carl Quinn created JENKINS-13148:


 Summary: Quick Search should include disabled jobs in is corpus
 Key: JENKINS-13148
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13148
 Project: Jenkins
  Issue Type: Bug
  Components: core
Reporter: Carl Quinn


Otherwise, how will people find them to clean re-enable or delete them?

I saw this problem in 1.428, but it may be fixed in a later rev.

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

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

gbois commented on JENKINS-13119:
-

Maybe a JBOSS issue with Groovy.
Do you have the ability to test on another servlet container such as Tomcat?

How can I set an environment variable based on value of user passed parameter?
--

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

2012-03-19 Thread sku...@gcefederal.com (JIRA)


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

suresh kukalakuntla commented on JENKINS-13119:
---

I am able to to put the required jar file in the lib folder of jenkins.war and 
I am able to use ENVInject successfully. 

Right now I am trying to test Evaluated Groovy script. Tried the below and got 
and error

[EnvInject] - Evaluation the following Groovy script content: 
if (MODULE_NAME==null){ return null; }

if (ACCT.equals(MODULE_NAME)){ def map = [MODULE_HOME: SSP-AM] return map 
}

if (FPD.equals(MODULE_NAME)){ def map = [MODULE_HOME: SSP-FPD] return map 
}

[EnvInject] - [ERROR] - SEVERE ERROR occurs: startup failed:
Script1.groovy: 3: expecting '}', found 'return' @ line 3, column 70.
   p = [MODULE_HOME: SSP-AM] return map
 ^

1 error

 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-9116) Doesn't handle group matches that are null

2012-03-19 Thread ever...@free.fr (JIRA)


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

evernat commented on JENKINS-9116:
--

@pgweiss
it seems that you have committed that change so this issue is probably fixed:
https://github.com/jenkinsci/description-setter-plugin/commit/8c19a4d8a8775303d6a7c30cf07282b40fc34c5e

and it was released in the plugin v1.8

 Doesn't handle group matches that are null
 --

 Key: JENKINS-9116
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9116
 Project: Jenkins
  Issue Type: Bug
  Components: description-setter
Reporter: pgweiss
Assignee: huybrechts

 If my regex is:
 ^URL: (\S)+( .*)?$
 And my replacement text is:
 a href=\1My URL\2/a
 It is possible that the regex can succeed and the matcher.group(2) will be 
 null.  If that happens the description setter fails like this:
 ERROR: Publisher hudson.plugins.descriptionsetter.DescriptionSetterPublisher 
 aborted due to exception
 java.lang.NullPointerException
   at java.lang.String.replace(String.java:2208)
   at 
 hudson.plugins.descriptionsetter.DescriptionSetterPublisher.getExpandedDescription(DescriptionSetterPublisher.java:158)
   at 
 hudson.plugins.descriptionsetter.DescriptionSetterPublisher.perform(DescriptionSetterPublisher.java:80)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:644)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:623)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:601)
   at hudson.model.Build$RunnerImpl.post2(Build.java:159)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:570)
   at hudson.model.Run.run(Run.java:1386)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:145)
 This can probably be fixed by changing:
 result = result.replace(\\ + i, matcher.group(i))
 to 
 result = result.replace(\\ + i, matcher.group(i) == null ? '' : 
 matcher.group(i))
 But I haven't actually checked 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-9116) Doesn't handle group matches that are null

2012-03-19 Thread ever...@free.fr (JIRA)


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

evernat resolved JENKINS-9116.
--

Resolution: Fixed

 Doesn't handle group matches that are null
 --

 Key: JENKINS-9116
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9116
 Project: Jenkins
  Issue Type: Bug
  Components: description-setter
Reporter: pgweiss
Assignee: huybrechts

 If my regex is:
 ^URL: (\S)+( .*)?$
 And my replacement text is:
 a href=\1My URL\2/a
 It is possible that the regex can succeed and the matcher.group(2) will be 
 null.  If that happens the description setter fails like this:
 ERROR: Publisher hudson.plugins.descriptionsetter.DescriptionSetterPublisher 
 aborted due to exception
 java.lang.NullPointerException
   at java.lang.String.replace(String.java:2208)
   at 
 hudson.plugins.descriptionsetter.DescriptionSetterPublisher.getExpandedDescription(DescriptionSetterPublisher.java:158)
   at 
 hudson.plugins.descriptionsetter.DescriptionSetterPublisher.perform(DescriptionSetterPublisher.java:80)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:644)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:623)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:601)
   at hudson.model.Build$RunnerImpl.post2(Build.java:159)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:570)
   at hudson.model.Run.run(Run.java:1386)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:145)
 This can probably be fixed by changing:
 result = result.replace(\\ + i, matcher.group(i))
 to 
 result = result.replace(\\ + i, matcher.group(i) == null ? '' : 
 matcher.group(i))
 But I haven't actually checked 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-12880) Enable the selection of the brower/version/operating system for single Jobs

2012-03-19 Thread piar...@gmail.com (JIRA)


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

Ross Rowe resolved JENKINS-12880.
-

Resolution: Fixed

 Enable the selection of the brower/version/operating system for single Jobs
 ---

 Key: JENKINS-12880
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12880
 Project: Jenkins
  Issue Type: Improvement
  Components: sauce-ondemand
Reporter: Ross Rowe
Assignee: Ross Rowe

 Currently, the only way to select the browser/version/operating system to be 
 used for Selenium tests run under Sauce OnDemand is via the Multi-config job.
 The plugin should be updated to allow for the selection of the 
 browser/version/operating system combination that will be used for single 
 Jobs.

--
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-12741) Improve support for multi-config Jobs

2012-03-19 Thread piar...@gmail.com (JIRA)


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

Ross Rowe resolved JENKINS-12741.
-

Fix Version/s: current
   Resolution: Fixed

 Improve support for multi-config Jobs
 -

 Key: JENKINS-12741
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12741
 Project: Jenkins
  Issue Type: Bug
  Components: sauce-ondemand
Reporter: Ross Rowe
Assignee: Ross Rowe
 Fix For: current


 The current Sauce Connect logic ensures that only a single Sauce Connect 
 instance is active per Job. For multi-config Jobs, this means that each Job 
 waits until previous Jobs have finished. 
 The plugin should be updated such that a single Sauce Connect instance is 
 active for all multi-config Job instances.

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


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

gbois commented on JENKINS-13119:
-

Try to use return line

Copy paste the following script, it should work

if (MODULE_NAME==null){ return null; }

if (ACCT.equals(MODULE_NAME)){ 
  def map = [MODULE_HOME: SSP-AM] 
  return map
}

if (FPD.equals(MODULE_NAME)){ 
  def map = [MODULE_HOME: SSP-FPD]
  return map
}


 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-7830) using environment variable for local port of ssh tunnel

2012-03-19 Thread piar...@gmail.com (JIRA)


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

Ross Rowe resolved JENKINS-7830.


Fix Version/s: current
   Resolution: Fixed

 using environment variable for local port of ssh tunnel
 ---

 Key: JENKINS-7830
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7830
 Project: Jenkins
  Issue Type: New Feature
  Components: sauce-ondemand
Reporter: scytacki
Assignee: Ross Rowe
 Fix For: current


 I use an environment variable to set the port used by the local server that I 
 want to test.  I do this because we want to be able to build/test the hudson 
 job on multiple slave nodes at the same time.  We currently have those slave 
 nodes running on the same machine. If the port is hard coded then I can't 
 startup multiple local servers at the same time because the port will be the 
 same for each and will conflict.
 So it would be helpful if the sauce-ondemand plugin would allow using 
 environment variables for the Local Port setting.

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


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

gbois commented on JENKINS-13119:
-

Wiki removes return line.
Otherwise, add a semicolon, for example:

if (MODULE_NAME==null){ return null; }

if (ACCT.equals(MODULE_NAME)){ def map = [MODULE_HOME: SSP-AM] ; return map 
}

if (FPD.equals(MODULE_NAME)){ def map = [MODULE_HOME: SSP-FPD] ; return map 
}


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


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

gbois commented on JENKINS-13113:
-

MSTest plugin is an independent plugin, written before xUnit. xUnit plugin is 
aimed at supporting all xUnit tools. 
Each plugin delegated his process to an XSL. And xUnit plugin uses a copy of 
the MSTest XSL.
Maybe, the xsl has been fixed in MSTest plugin but not in the xUnit plugin.

Therefore, could you try with MSTest?

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:
 UnitTestResult executionId=88518b81-226a-4fe9-9896-774a00c13e8e 
 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
 /UnitTestResult
 The transformation in the junitResult.xml file:
   case
   durationNaN/duration 
   classNameConformanceWcdmaCompleteTest.BandSpecificTests/className 
   testNameTestcaseWcdmaTxIntermod_5_12__FDD9/testName 
   skippedfalse/skipped 
   failedSince0/failedSince 
   /case

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


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

Work on JENKINS-13113 started by gbois.

 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:
 UnitTestResult executionId=88518b81-226a-4fe9-9896-774a00c13e8e 
 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
 /UnitTestResult
 The transformation in the junitResult.xml file:
   case
   durationNaN/duration 
   classNameConformanceWcdmaCompleteTest.BandSpecificTests/className 
   testNameTestcaseWcdmaTxIntermod_5_12__FDD9/testName 
   skippedfalse/skipped 
   failedSince0/failedSince 
   /case

--
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-13142) launch the app after installing

2012-03-19 Thread ch...@orr.me.uk (JIRA)


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

Christopher Orr commented on JENKINS-13142:
---

Yup, could do.  In most cases there will be only one launcher activity, though 
in the case of multiple, I'd just use the first launchable-activity listed by 
`aapt dump badging`.  Otherwise, we could add an advanced field where the 
component name can be specified.

Which test tools are you using which require the app to be running, and don't 
launch it themselves?

 launch the app after installing
 ---

 Key: JENKINS-13142
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13142
 Project: Jenkins
  Issue Type: New Feature
  Components: android-emulator
Reporter: Justin Shacklette
Assignee: Christopher Orr
Priority: Minor

 The Android Emulator plugin lets you install the APK, but not launch it.
 It'd be awesome if you could also launch the installed APK. Maybe another 
 checkbox alongside the existing Uninstall existing APK first checkbox that 
 says Launch after installing APK
 It's easy to launch an app with adb:
 adb shell am start -n com.package.name/com.package.name.ActivityName
 This feature would be great because some automated testing usecases require 
 the app to be running.

--
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-13136) Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)


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

gbois commented on JENKINS-13136:
-

Could you attach your job configuration file (config.xml)?

 Environment Variable Injection injecting (and overriding) unwanted variables 
 (ie JAVA_HOME)
 ---

 Key: JENKINS-13136
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13136
 Project: Jenkins
  Issue Type: Bug
  Components: envinject
Affects Versions: current
 Environment: Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
 Slave Node: Windows XP
 EnvInject: 1.38
Reporter: Alex Gray
Assignee: gbois

 We were using EnvInject 1.35 in various free-style jobs, but after we 
 upgraded to 1.36 jobs started failing.
 This is the reason:
 1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is 
 pointing to version 1.25.  I can verify this by going to Jenkins-Manage 
 Jenkins-Manage Nodes-MyWinXPNode-view log, and sure enough the node's 
 environment variables have JAVA_HOME pointing to 1.25
 2) After upgraded to EnvInject 1.36, the jobs started failing because 
 JAVA_HOME has been overwritten to 1.27, which does not exist on the node.  In 
 fact, I don't know where this is being set because the master does not have 
 java 1.27 either!
 The only option that is is present in the job is this:
 Inject environment variables to the build process
 Properties Content:
 TEMP=c:\\windows\\temp
 TMP=c:\\windows\\temp
 (everything else under Inject Environment Variables is blank.
 I have not tried the latest version, 1.38, but I will, since all the jobs are 
 currently broken and I have nothing else to lose...
 If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but 
 that does not work on multiconfiguration jobs.
 I'll keep you posted.  If this is fixed in 1.38, I will update this Jira.

--
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-13099) More than one hardware device on one Jenkins server should be possible.

2012-03-19 Thread ch...@orr.me.uk (JIRA)

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

Christopher Orr commented on JENKINS-13099:
---

Sorry, I'm not clear on how you're using the plugin -- for the most part, this
plugin only relates to launching Android emulators.
Are you talking about the Install Android package feature?

Managing a pool of available Android devices and lending them to Jenkins jobs
would be useful, but that's probably not so straight forward, and better suited
to a separate plugin.

I believe Testdroid Cloud/Server does something similar to this, also based on
Jenkins.

Is your current bash-scripted method of automation available somewhere to see?
:)

More than one hardware device on one Jenkins server should be possible.
---

Key: JENKINS-13099
URL: https://issues.jenkins-ci.org/browse/JENKINS-13099
Project: Jenkins
Issue Type: New Feature
Components: android-emulator
Affects Versions: current
Reporter: Cat Roid
Assignee: Christopher Orr
Labels: android, plugin, testing

We run our Android unit tests on a Nexus S and want to plug in another one to
run more than one test build at once. We've not discovered a way to enable
two executors which will properly distribute the test builds.
The current error message is:
- waiting for device -
error: more than one device and emulator
We'd have to specify the free device via adb -s but not find a way to
properly automate this, except writing our own bash scripts. An official way
to do this would greatly help us. :)

[JIRA] (JENKINS-13107) Android NDK support not present for auto-dependency download

2012-03-19 Thread ch...@orr.me.uk (JIRA)


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

Christopher Orr commented on JENKINS-13107:
---

Yeah, I haven't really used the NDK, but this should be possible.

Would it be sufficient for the plugin to export an environment variable (e.g. 
ANDROID_NDK_HOME) during a build, pointing to the directory where the plugin 
extracted the NDK installation?

 Android NDK support not present for auto-dependency download
 

 Key: JENKINS-13107
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13107
 Project: Jenkins
  Issue Type: New Feature
  Components: android-emulator
Affects Versions: current
Reporter: Amy Winarske
Assignee: Christopher Orr

 The dependency download is very nice, but doesn't include the NDK, only the 
 SDK.  NDK support would be a big help.

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

[JIRA] (JENKINS-13096) should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) in the properties file path


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

gbois commented on JENKINS-13096:
-

Any update?

 should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) 
 in the properties file path
 -

 Key: JENKINS-13096
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13096
 Project: Jenkins
  Issue Type: Improvement
  Components: envinject
Affects Versions: current
Reporter: Maddy Goss
Assignee: gbois
Priority: Minor
  Labels: plugin

 I keep my generic project configuration in a properties file which is in a 
 project that is checked into SCM. I would like to be able to update that file 
 in a parent job, and then consume it (via 
 $WORKSPACE/projectname/global.properties). Currently, you have to use the 
 full path to the properties file, which makes my configuration brittle.

--
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-11248) Build fails on Deploy artifacts to Maven repository due to trying to upload parent POM twice for release artifacts

2012-03-19 Thread mrasmus...@luthresearch.com (JIRA)


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

Michael Rasmussen closed JENKINS-11248.
---


[~trekoid] has tested with his installation and is no longer seeing the issue.

 Build fails on Deploy artifacts to Maven repository due to trying to upload 
 parent POM twice for release artifacts
 

 Key: JENKINS-11248
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11248
 Project: Jenkins
  Issue Type: Bug
  Components: deploy, maven2
Affects Versions: current
 Environment: OS: CentOS release 5.5 (Final)
 Jenkins: 1.433
 Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+)
 Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-194.32.1.el5, arch: amd64, family: 
 unix
Reporter: Michael Rasmussen
Assignee: olamy
 Fix For: current


 Scenario: We have several sets of Java OSGi services with a parent pom and 4 
 child projects/poms. The parent pom does not generate any JARs, but each of 
 the children generates a jar.Something like the following:
 {noformat}
 project_folder/
   |_servicename.business/
   |   \_pom.xml
   |_servicename.jms/
   |   \_pom.xml
   |_servicename.model/
   |   \_pom.xml
   |_servicename.webservice/
   |   \_pom.xml
   \_pom.xml
 {noformat} 
 Each of these services is setup as a separate Jenkins job, and the maven 
 dependencies are turned on so they all build in the appropriate order.
 Within the parent pom we have our distributionManagement section defined so 
 we can run the mvn deploy goals to upload artifacts to our maven repository.
 Up until this point we have only been building SNAPSHOTS, for which the Nexus 
 repository allows redeploying of artifacts.
 WHAT IS GOING WRONG:
 The other day we tried to build our first release version of some of the 
 services, and the deployment into the Nexus maven repository failed on the 
 Deploy artifacts to Maven repository task.
 Looking at the Console Output of the failed job, for some reason Jenkins is 
 trying to deploy the parent POM a second time. Nexus refuses this, as it does 
 not allow redeploying of release artifacts. Below is an excerpt from the 
 output of one of those jobs:
 {quote}
 [INFO] 
 
 [INFO] BUILD SUCCESS
 [INFO] 
 
 [INFO] Total time: 52.240s
 [INFO] Finished at: Thu Oct 06 14:55:37 GMT 2011
 [INFO] Final Memory: 63M/151M
 [INFO] 
 
 channel stopped
 Maven RedeployPublished use remote  maven settings from : 
 /opt/maven/conf/settings.xml
 [ERROR] uniqueVersion == false is not anymore supported in maven 3
 [INFO] Deployment in 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/ 
 (id=com.luthresearch,uniqueVersion=false)
 Deploying the main artifact savvyconnect-1.0.1.pom
 Uploading: 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
 Uploaded: 
 dav:http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
  (3 KB at 24.4 KB/sec)
 Uploading: 
 http://maven.luthresearch.net/nexus/content/repositories/releases/com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom
 ERROR: Failed to deploy artifacts: Could not transfer artifact 
 com.luthresearch.savvyconnect:savvyconnect:pom:1.0.1 from/to com.luthresearch 
 (dav:http://maven.luthresearch.net/nexus/content/repositories/releases/): 
 Failed to transfer file: 
 http://maven.luthresearch.net/nexus/content/repositories/releases//com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom.
  Return code is: 400
 org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
 deploy artifacts: Could not transfer artifact 
 com.luthresearch.savvyconnect:savvyconnect:pom:1.0.1 from/to com.luthresearch 
 (dav:http://maven.luthresearch.net/nexus/content/repositories/releases/): 
 Failed to transfer file: 
 http://maven.luthresearch.net/nexus/content/repositories/releases//com/luthresearch/savvyconnect/savvyconnect/1.0.1/savvyconnect-1.0.1.pom.
  Return code is: 400
   at 
 org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
   at 
 hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:189)
   at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:158)
   at

[JIRA] (JENKINS-12650) jenkins running in Tomcat doesn't initalize slf4j properly


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

SCM/JIRA link daemon commented on JENKINS-12650:


Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 maven-plugin/pom.xml
 pom.xml
 war/pom.xml
http://jenkins-ci.org/commit/jenkins/7cc71cd78ea5839bec9a4c881c00751dde9b5b5a
Log:
  [FIXED JENKINS-12334 JENKINS-12446 JENKINS-12650]

Bundle slf4j binding to the war.
See the comment in war/pom.xml for detailed discussion.

This is fundamentally a damned if I do, damned if I don't situation,
but given that JENKINS-12334 is a fatal error, and the downside of
bundling the binding jar is multiple binding warning, it seems like
the lesser evil is to bundle it and risk some warnings.

Cherry-picked-from: ef1ad6ca29c313fa0b4bc6f5dcd8344046221049




 jenkins running in Tomcat doesn't initalize slf4j properly
 --

 Key: JENKINS-12650
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12650
 Project: Jenkins
  Issue Type: Bug
  Components: ssh
 Environment: jenkins 1.450, tomcat 7.0.23, java 1.6.0-30
Reporter: Alex Lehmann
Assignee: Kohsuke Kawaguchi
Priority: Minor

 when running tomcat, the slf4j library isn't correctly initialized, this is 
 not a problem by itself since it simply turns off logging completely for the 
 components that use slf, however if the logging output is needed for a 
 component it would be better to provide the simple logger.
 SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 SLF4J: Defaulting to no-operation (NOP) logger implementation
 SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
 details.
 when I put the necessary jar into the war, the log output becomes this:
 16 [NullIdDescriptorMonitor.verifyId] INFO 
 org.apache.sshd.common.util.SecurityUtils - Trying to register BouncyCastle 
 as a JCE provider
 511 [NullIdDescriptorMonitor.verifyId] INFO 
 org.apache.sshd.common.util.SecurityUtils - Registration succeeded
 so this is used by the sshd module in the default installation.
 Alternatively, the binding for jdk14 logging or log4j could be used (which 
 ever is more fitting for the rest of jenkins).

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

[JIRA] (JENKINS-12334) jenkins does not start in jboss container


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

SCM/JIRA link daemon commented on JENKINS-12334:


Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 maven-plugin/pom.xml
 pom.xml
 war/pom.xml
http://jenkins-ci.org/commit/jenkins/7cc71cd78ea5839bec9a4c881c00751dde9b5b5a
Log:
  [FIXED JENKINS-12334 JENKINS-12446 JENKINS-12650]

Bundle slf4j binding to the war.
See the comment in war/pom.xml for detailed discussion.

This is fundamentally a damned if I do, damned if I don't situation,
but given that JENKINS-12334 is a fatal error, and the downside of
bundling the binding jar is multiple binding warning, it seems like
the lesser evil is to bundle it and risk some warnings.

Cherry-picked-from: ef1ad6ca29c313fa0b4bc6f5dcd8344046221049




 jenkins does not start in jboss container
 -

 Key: JENKINS-12334
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12334
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: JBoss 5.1 EAP
Reporter: Terry Sposato
Assignee: Kohsuke Kawaguchi
Priority: Blocker
  Labels: jenkins

 Using latest RC version of jenkins, starting jboss up gives these errors:
 2012-01-09 16:07:06,859 INFO  [org.jboss.bootstrap.microcontainer.ServerImpl] 
 (main) JBoss (Microcontainer) [5.1.0 (build: SVNTag=JBPAPP_5_1_0 
 date=201009150028)] Started in 32s:316ms
 2012-01-09 16:07:07,305 INFO  [jenkins.InitReactorRunner] (pool-14-thread-2) 
 Started initialization
 2012-01-09 16:07:09,553 INFO  [jenkins.InitReactorRunner] (pool-14-thread-4) 
 Listed all plugins
 2012-01-09 16:07:13,601 INFO  [jenkins.InitReactorRunner] (pool-14-thread-2) 
 Prepared all plugins
 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) 
 SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding.
 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) 
 SLF4J: Your binding is version 1.5.5 or earlier.
 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) 
 SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x
 2012-01-09 16:07:18,637 WARNING [hudson.ExtensionFinder$GuiceFinder] 
 (Initializing plugin copyartifact) Failed to instantiate. Skipping this 
 component
 com.google.inject.ProvisionException: Guice provision errors:
 1) Error injecting constructor, java.lang.NoSuchMethodError: 
 org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder;
   at org.jenkinsci.main.modules.sshd.SSHD.init(SSHD.java:40)
 1 error
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at 
 com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:54)
 at 
 com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:118)
 at 
 com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:117)
 at 
 com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
 at 
 com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at 
 com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
 at 
 com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
 at 
 hudson.ExtensionFinder$AbstractGuiceFinder._find(ExtensionFinder.java:336)
 at 
 hudson.ExtensionFinder$AbstractGuiceFinder.find(ExtensionFinder.java:327)
 at hudson.ExtensionFinder._find(ExtensionFinder.java:147)
 at 
 hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:289)
 at hudson.ExtensionList.load(ExtensionList.java:278)

[JIRA] (JENKINS-8152) LDAP config error


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

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

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 core/src/main/java/hudson/security/LDAPSecurityRealm.java
http://jenkins-ci.org/commit/jenkins/fa95a3a439584e6a19349360c6c4f68a7a404e01
Log:
  [FIXED JENKINS-8152]

Formatting error in the rootDN inference code. It shouldn't include
attribute name.

Cherry-picked-from: c99fc315dddf707dba3a2dea6a048bd76dce4c2e


Compare: https://github.com/jenkinsci/jenkins/compare/a7e3bae...fa95a3a



 LDAP config error
 -

 Key: JENKINS-8152
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8152
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Hudson 1.386; Windows XP; Hudson's built-in container 
 (no Tomcat)
Reporter: cjyar

 Configuring LDAP authentication in Hudson:
 Server: ldaps://directory.sri.com
 root DN: o=SRI International,c=US
 User search base:
 User search filter: uid={0}
 Group search base:
 Manager DN:
 Manager Password:
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'initialDirContextFactory': Instantiation of bean failed; nested 
 exception is org.springframework.beans.BeanInstantiationException: Could not 
 instantiate bean class 
 [org.acegisecurity.ldap.DefaultInitialDirContextFactory]: Constructor threw 
 exception; nested exception is java.lang.IllegalArgumentException: Root DNs 
 must be the same when using multiple URLs
   at 
 org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:231)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:957)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:869)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:514)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
   at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:169)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:170)
   at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:413)
   at 
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:735)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:369)
   at 
 hudson.util.spring.DefaultRuntimeSpringConfiguration.getApplicationContext(DefaultRuntimeSpringConfiguration.java:94)
   at 
 hudson.util.spring.BeanBuilder.createApplicationContext(BeanBuilder.java:388)
   at 
 hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:344)
   at 
 hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:359)
   at hudson.security.HudsonFilter.reset(HudsonFilter.java:134)
   at hudson.model.Hudson.setSecurityRealm(Hudson.java:1833)
   at hudson.model.Hudson.doConfigSubmit(Hudson.java:2345)
   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: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:102)
   at 
 org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562)
   at

[JIRA] (JENKINS-13097) File handle leak in serving static files


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

SCM/JIRA link daemon commented on JENKINS-13097:


Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 core/pom.xml
http://jenkins-ci.org/commit/jenkins/e1fe985bce9f6c2ee82ed6670433f5a92c738a35
Log:
  [FIXED JENKINS-13097]




 File handle leak in serving static files
 

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

 {noformat}
   at java.io.FileInputStream.init(FileInputStream.java:121)
   at java.io.FileInputStream.init(FileInputStream.java:79)
   at 
 sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
   at 
 sun.net.www.protocol.file.FileURLConnection.initializeHeaders(FileURLConnection.java:90)
   at 
 sun.net.www.protocol.file.FileURLConnection.getHeaderField(FileURLConnection.java:126)
   at 
 sun.net.www.protocol.jar.JarURLConnection.getHeaderField(JarURLConnection.java:203)
   at java.net.URLConnection.getHeaderFieldDate(URLConnection.java:603)
   at java.net.URLConnection.getLastModified(URLConnection.java:532)
   at org.kohsuke.stapler.Stapler.serveStaticResource(Stapler.java:241)
   at org.kohsuke.stapler.Stapler.serveStaticResource(Stapler.java:252)
   at org.kohsuke.stapler.ResponseImpl.serveFile(ResponseImpl.java:132)
   at 
 org.kohsuke.stapler.framework.adjunct.AdjunctManager.doDynamic(AdjunctManager.java:129)
   at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 {noformat}
 There's a file handle leak in {{Stapler.serveStaticResource}} that badly 
 affects busy instances. I've fixed this in Stapler 1.182.

--
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-12446) java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder


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

SCM/JIRA link daemon commented on JENKINS-12446:


Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 maven-plugin/pom.xml
 pom.xml
 war/pom.xml
http://jenkins-ci.org/commit/jenkins/7cc71cd78ea5839bec9a4c881c00751dde9b5b5a
Log:
  [FIXED JENKINS-12334 JENKINS-12446 JENKINS-12650]

Bundle slf4j binding to the war.
See the comment in war/pom.xml for detailed discussion.

This is fundamentally a damned if I do, damned if I don't situation,
but given that JENKINS-12334 is a fatal error, and the downside of
bundling the binding jar is multiple binding warning, it seems like
the lesser evil is to bundle it and risk some warnings.

Cherry-picked-from: ef1ad6ca29c313fa0b4bc6f5dcd8344046221049




 java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
 -

 Key: JENKINS-12446
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12446
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Linux
Reporter: aaronlab
Assignee: Kohsuke Kawaguchi
Priority: Blocker
 Attachments: winstone.log


 This issue started happening since 1.446+ (meaning, 446, 447, 448).  
 Apparently either jenkins core or some plugin is using slf4j, but neither 
 Jenkins, nor the plugin ships with any slf4 implementations, resulting the in 
 following stack trace on startup...
 Failed to instantiate SLF4J LoggerFactory
 Reported exception:
 java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
 at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
 at 
 org.slf4j.LoggerFactory.performInitialization(LoggerFactory.javCaused by: 
 java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder
 at 
 java.lang.ClassNotFoundException.init(ClassNotFoundException.java:77)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1524)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
 ... 22 more
 I was able to get Jenkins to start fine by manually downloading the 
 slf4j-simple directly from maven and putting it into WEB-INF/lib... but, 
 without that file, Jenkins is 100% unusable.
 http://repo2.maven.org/maven2/org/slf4j/slf4j-simple/1.6.1/slf4j-simple-1.6.1.jar

--
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-12302) Remote call on CLI channel from [ip] failed


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

SCM/JIRA link daemon commented on JENKINS-12302:


Code changed in jenkins
User: Vojtech Juranek
Path:
 core/src/main/java/hudson/cli/GroovyCommand.java
 core/src/main/java/hudson/cli/util/ScriptLoader.java
http://jenkins-ci.org/commit/jenkins/99385dcd1c8a2dc84d51133f1f4b06d4bc1cf653
Log:
  [FIXED JENKINS-12302] Refactor anonymout class for loading groovy script into 
separate class as static block (due to inheritance of outer class from 
CLICommand) initialization leads to NPE (namely in Jenkins.getInstance 
Jenkins.getInstance().getPluginManager())
(cherry picked from commit 7bdc1790166198de93b2b7c58286d9554be967b4)




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

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

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

[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-19 Thread alexl...@gmail.com (JIRA)


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

Alex Lehmann commented on JENKINS-13129:


i think i found the cause, there is problem with the isBundled property in 
plugins, I will write a patch tomorrow.



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

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

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

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

[JIRA] (JENKINS-13147) Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins with different cases in their path not to get excluded

2012-03-19 Thread rob.pe...@gmail.com (JIRA)


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

Rob Petti reassigned JENKINS-13147:
---

Assignee: Rob Petti

 Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins 
 with different cases in their path not to get excluded
 

 Key: JENKINS-13147
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13147
 Project: Jenkins
  Issue Type: Improvement
  Components: perforce
Affects Versions: current
Reporter: Patrick McKeown
Assignee: Rob Petti
Priority: Minor

 Say I am excluding //depot/Branch/*
 If someone checks in a file
 //depot/Branch/test.txt
 it will properly be exluded
 but if they check in a file as 
 //depot/branch/test.txt
 the case difference will cause it to not be excluded.
 The problem stems from the fact that you can add files to perforce with 
 different cases because it is case insensitive.  
 I would like the exclude list to be case insensitive as well, or at least add 
 an option for it to be.  
 Thanks for the awesome plugin!

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

[JIRA] (JENKINS-13147) Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins with different cases in their path not to get excluded

2012-03-19 Thread rob.pe...@gmail.com (JIRA)


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

Rob Petti commented on JENKINS-13147:
-

I made it case sensitive because every perforce server I have come across (we 
have 5 at my company) has been case sensitive. I'll add an option for it, 
though.

 Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins 
 with different cases in their path not to get excluded
 

 Key: JENKINS-13147
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13147
 Project: Jenkins
  Issue Type: Improvement
  Components: perforce
Affects Versions: current
Reporter: Patrick McKeown
Priority: Minor

 Say I am excluding //depot/Branch/*
 If someone checks in a file
 //depot/Branch/test.txt
 it will properly be exluded
 but if they check in a file as 
 //depot/branch/test.txt
 the case difference will cause it to not be excluded.
 The problem stems from the fact that you can add files to perforce with 
 different cases because it is case insensitive.  
 I would like the exclude list to be case insensitive as well, or at least add 
 an option for it to be.  
 Thanks for the awesome plugin!

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

[JIRA] (JENKINS-12573) CVS plugin version 2.0 checkout failed: Can't parse date/time

2012-03-19 Thread cof...@gmail.com (JIRA)


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

Eric Co commented on JENKINS-12573:
---

After update to version 2.1, I still got the error:

Building on master
cvs checkout -P -D 20 Mar 2012 10:33:34 HKT -d workspace abc
cvs [checkout aborted]: Can't parse date/time: 20 Mar 2012 10:33:34 HKT

 CVS plugin version 2.0 checkout failed: Can't parse date/time
 -

 Key: JENKINS-12573
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12573
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
Affects Versions: current
 Environment: Jenkins ver. 1.424.2
 Jenkins CVS Plug-in 2.0
Reporter: Eric Co
Assignee: Michael Clarke

 After I upgraded the CVS plugin 2.0, got the following error:
   cvs checkout -P -D 2012-01-30 16:37:44HKT -d abc abc
   cvs [checkout aborted]: Can't parse date/time: 2012-01-30 16:37:44HKT

--
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-12573) CVS plugin version 2.0 checkout failed: Can't parse date/time

2012-03-19 Thread cof...@gmail.com (JIRA)


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

Eric Co reopened JENKINS-12573:
---


Building on master
cvs checkout -P -D 20 Mar 2012 10:33:34 HKT -d workspace abc
cvs [checkout aborted]: Can't parse date/time: 20 Mar 2012 10:33:34 HKT

 CVS plugin version 2.0 checkout failed: Can't parse date/time
 -

 Key: JENKINS-12573
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12573
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
Affects Versions: current
 Environment: Jenkins ver. 1.424.2
 Jenkins CVS Plug-in 2.0
Reporter: Eric Co
Assignee: Michael Clarke

 After I upgraded the CVS plugin 2.0, got the following error:
   cvs checkout -P -D 2012-01-30 16:37:44HKT -d abc abc
   cvs [checkout aborted]: Can't parse date/time: 2012-01-30 16:37:44HKT

--
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-13147) Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins with different cases in their path not to get excluded


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

SCM/JIRA link daemon commented on JENKINS-13147:


Code changed in jenkins
User: Rob Petti
Path:
 src/main/java/hudson/plugins/perforce/PerforceSCM.java
 src/main/resources/hudson/plugins/perforce/PerforceSCM/config.jelly
 src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
http://jenkins-ci.org/commit/perforce-plugin/d825526215b0a3f1ae9a172d6f3e33ff0b3dab8f
Log:
  [FIXED JENKINS-13147] Added case sensitivity option for exclusion of files 
during polling






 Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins 
 with different cases in their path not to get excluded
 

 Key: JENKINS-13147
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13147
 Project: Jenkins
  Issue Type: Improvement
  Components: perforce
Affects Versions: current
Reporter: Patrick McKeown
Assignee: Rob Petti
Priority: Minor

 Say I am excluding //depot/Branch/*
 If someone checks in a file
 //depot/Branch/test.txt
 it will properly be exluded
 but if they check in a file as 
 //depot/branch/test.txt
 the case difference will cause it to not be excluded.
 The problem stems from the fact that you can add files to perforce with 
 different cases because it is case insensitive.  
 I would like the exclude list to be case insensitive as well, or at least add 
 an option for it to be.  
 Thanks for the awesome plugin!

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

[JIRA] (JENKINS-13147) Perforce Plugin's Poll Exclude File(s) is case sensitive causing checkins with different cases in their path not to get excluded