date:20120319

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 
org.apache.commons.jelly.tag

[JIRA] (JENKINS-13134) Disk usage link doesn't work for view tabs

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


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

vjuranek resolved JENKINS-13134.


Resolution: Duplicate

Hi, this is duplicate of JENKINS-12917 - already fixed, will be in the next 
release.

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

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 sebastian.sickelm...@continentale.de (JIRA)


[ 
https://issues.jenkins-ci.org/browse/JENKINS-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:


   
   
  ...
   


> 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-tabpanel&focusedCommentId=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."

Test file extraction:


   
   
  ...
   


  was (Author: matthiasscholz):
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:


   
   
  ...
   

  
> 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: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
>
>
> 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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-13086) Clone to directory named for repository

2012-03-19 Thread rmorgenst...@voltdb.com (JIRA)


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

Ruth Morgenstein commented on JENKINS-13086:


Use the Multiple SCM plugin. Make sure you set the Advanced setting:"Unique SCM 
name (optional)".
https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin

> Clone to directory named for repository
> ---
>
> Key: JENKINS-13086
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13086
> Project: Jenkins
>  Issue Type: New Feature
>  Components: git
>Affects Versions: current
>Reporter: Tom Haggie
>Assignee: Nicolas De Loof
>Priority: Minor
>  Labels: git, jenkins
>
> In a Jenkins Job you can select to use git to clone / pull from multiple 
> repositories but it always pulls straight to the working directory so if you 
> have multiple they end up overwriting each other.
> What I'd like is a checkbox to say clone to a directory (under the workspace) 
> named for the git repository.
> So (when checked) if I had the command as: 
> https://github.com/jenkinsci/jenkins.git
> it would checkout to .../workspace/job_name/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-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-tabpanel&focusedCommentId=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:20

[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-tabpanel&focusedCommentId=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
>Pr

[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 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(H

[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-tabpanel&focusedCommentId=160403#comment-160403
 ] 

Alex Gray commented on JENKINS-13136:
-

I take my previous comment back.  This is still broken in 1.38.
I think the scenario is as follows:
1) Inject env variables from property file located on master
2) ~check out from SCM occurrs~
3) Inject env variables from Properties Content
4) Bam: Your PATH, JAVA_HOME, etc has now been replaced with the Master's env 
vars, not the slaves.



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


 [ 
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


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

Ed Randall updated JENKINS-10520:
-

Attachment: clone-workspace

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

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


[ 
https://issues.jenkins-ci.org/browse/JENKINS-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

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

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

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

[
https://issues.jenkins-ci.org/browse/JENKINS-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:

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

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.

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 th

[JIRA] (JENKINS-13138) Verify action doesn't work with CSRF option

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

 Summary: 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
 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-7444) Distributed builds: Scheduling strategy

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


[ 
https://issues.jenkins-ci.org/browse/JENKINS-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

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

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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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, 
List 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
  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)
a

[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:
  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)
at org.k

[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:
  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)

[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-12835) NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 0.4


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

Christian Höltje commented on JENKINS-12835:


Ditto on Jenkins 1.455.

> NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 
> 0.4
> ---
>
> Key: JENKINS-12835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12835
> Project: Jenkins
>  Issue Type: Bug
>  Components: clone-workspace-scm
>Affects Versions: current
> Environment: Jenkins 1.424.2
> Jenkins Clone Workspace SCM Plug-in 0.4
>Reporter: Ed Randall
>
> After upgrading clone-workspace-plugin from 0.3 to 0.4 this happens at the 
> end of the job when it is supposed to start archiving:-
> BUILD SUCCESSFUL
> Total time: 5 minutes 1 second
> Archiving workspace
> ERROR: Publisher hudson.plugins.cloneworkspace.CloneWorkspacePublisher 
> aborted due to exception
> java.lang.NullPointerException
>   at 
> hudson.plugins.cloneworkspace.CloneWorkspacePublisher.snapshot(CloneWorkspacePublisher.java:211)
>   at 
> hudson.plugins.cloneworkspace.CloneWorkspacePublisher.perform(CloneWorkspacePublisher.java:170)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:682)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:657)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:635)
>   at hudson.model.Build$RunnerImpl.post2(Build.java:161)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:604)
>   at hudson.model.Run.run(Run.java:1400)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:175)
> Email was triggered for: Failure

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

2012-03-19 Thread outro...@mail.ru (JIRA)


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

Alexander Potapov commented on JENKINS-11248:
-

Today I had similar problem. I don't know if my issue related to this one 
mentioned here...
But I have Nexus repository which is configured for releases.
When I was trying to deploy snapshot there I got similar exception (Return code 
is: 400, ReasonPhrase:Bad Request).
After changing project version in POM to non snapshot version, build succeeded.
Maybe it is related to maven repository setup or repository URLs specified, for 
instance, in POM file.
Anyway, I think you are trying to deploy snapshot into releases repository.


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

[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-tabpanel&focusedCommentId=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:///nexus/content/repositories/*releases*/ and 
http:///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  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.

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

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.

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 
"CentOS&&firefox&&jruby" (assuming you have a node like that)
* Restart Jenkins
* build the job

Notice how it says that no nodes exist for "CentOS&&firefox&&jruby". 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.

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

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



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.

--
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-13043) Test Results Trend graph missing intermittently

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


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

redsolo commented on JENKINS-13043:
---

Is this similar to the problem discussed in JENKINS-9965 ?

> Test Results Trend graph missing intermittently
> ---
>
> Key: JENKINS-13043
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13043
> Project: Jenkins
>  Issue Type: Bug
>  Components: nunit
>Affects Versions: current
> Environment: Windows 2008R2 running Jenkins as a service. This isn't 
> an error, it's more of a bad state, so there's no stack trace to show. Here's 
> the /systemInfo dump:
> Name   Value
> awt.toolkit sun.awt.windows.WToolkit 
> executable-war C:\Apps\Jenkins\jenkins.war 
> file.encoding Cp1252 
> file.encoding.pkg sun.io 
> file.separator \ 
> hudson.diyChunking true 
> hudson.lifecycle hudson.lifecycle.WindowsServiceLifecycle 
> java.awt.graphicsenv sun.awt.Win32GraphicsEnvironment 
> java.awt.headless true 
> java.awt.printerjob sun.awt.windows.WPrinterJob 
> java.class.path C:\Apps\Jenkins\jenkins.war 
> java.class.version 50.0 
> java.endorsed.dirs C:\Apps\Jenkins\jre\lib\endorsed 
> java.ext.dirs C:\Apps\Jenkins\jre\lib\ext;C:\Windows\Sun\Java\lib\ext 
> java.home C:\Apps\Jenkins\jre 
> java.io.tmpdir C:\Windows\TEMP\ 
> java.library.path 
> C:\Apps\Jenkins\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\csvn\bin\;C:\csvn\Python25\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program
>  Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft 
> SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL 
> Server\100\DTS\Binn\;c:\Program Files (x86)\Microsoft SQL 
> Server\100\Tools\Binn\VSShell\Common7\IDE\;c:\Program Files (x86)\Microsoft 
> SQL Server\100\DTS\Binn\;C:\Program Files\NCover\;C:\Program Files\Microsoft 
> Windows Performance Toolkit\;c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET 
> Web Pages\v1.0\;;. 
> java.runtime.name Java(TM) SE Runtime Environment 
> java.runtime.version 1.6.0_26-b03 
> java.specification.name Java Platform API Specification 
> java.specification.vendor Sun Microsystems Inc. 
> java.specification.version 1.6 
> java.vendor Sun Microsystems Inc. 
> java.vendor.url http://java.sun.com/ 
> java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi 
> java.version 1.6.0_26 
> java.vm.info mixed mode 
> java.vm.name Java HotSpot(TM) Client VM 
> java.vm.specification.name Java Virtual Machine Specification 
> java.vm.specification.vendor Sun Microsystems Inc. 
> java.vm.specification.version 1.0 
> java.vm.vendor Sun Microsystems Inc. 
> java.vm.version 20.1-b02 
> line.separator  
> mail.smtp.sendpartial true 
> mail.smtps.sendpartial true 
> os.arch x86 
> os.name Windows Server 2008 R2 
> os.version 6.1 
> path.separator ; 
> sun.arch.data.model 32 
> sun.boot.class.path 
> C:\Apps\Jenkins\jre\lib\resources.jar;C:\Apps\Jenkins\jre\lib\rt.jar;C:\Apps\Jenkins\jre\lib\sunrsasign.jar;C:\Apps\Jenkins\jre\lib\jsse.jar;C:\Apps\Jenkins\jre\lib\jce.jar;C:\Apps\Jenkins\jre\lib\charsets.jar;C:\Apps\Jenkins\jre\lib\modules\jdk.boot.jar;C:\Apps\Jenkins\jre\classes
>  
> sun.boot.library.path C:\Apps\Jenkins\jre\bin 
> sun.cpu.endian little 
> sun.cpu.isalist pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 
> sun.desktop windows 
> sun.io.unicode.encoding UnicodeLittle 
> sun.java.command C:\Apps\Jenkins\jenkins.war --httpPort=8080 
> sun.java.launcher SUN_STANDARD 
> sun.jnu.encoding Cp1252 
> sun.management.compiler HotSpot Client Compiler 
> sun.os.patch.level Service Pack 1 
> svnkit.http.methods Digest,Basic,NTLM,Negotiate 
> svnkit.ssh2.persistent false 
> user.country US 
> user.dir C:\Windows\system32 
> user.home C:\ 
> user.language en 
> user.name $ 
> user.timezone America/Chicago 
> user.variant  
> Environment Variables
> Name  ↓ Value
> ALLUSERSPROFILE C:\ProgramData 
> APPDATA C:\Windows\system32\config\systemprofile\AppData\Roaming 
> APR_ICONV1_PATH C:\csvn\bin\iconv\ 
> BASE C:\Apps\Jenkins 
> COMPUTERNAME 28SVMSVNCI051 
> ComSpec C:\Windows\system32\cmd.exe 
> CommonProgramFiles C:\Program Files (x86)\Common Files 
> CommonProgramFiles(x86) C:\Program Files (x86)\Common Files 
> CommonProgramW6432 C:\Program Files\Common Files 
> FP_NO_HOST_CHECK NO 
> JAVA_HOME C:\Program Files (x86)\Java\jdk1.6.0_27 
> JENKINS_HOME C:\Apps\Jenkins 
> LOCALAPPDATA C:\Windows\system32\config\systemprofile\AppData\Local 
> NUMBER_OF_PROCESSORS 2 
> OS Windows_NT 
> PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC 
> PROCESSOR_ARCHITECTURE x86 
> PROCESSOR_ARCHITEW6432 AMD64 
> PROCESSOR_IDENTIFIER Intel64 Family 6 Model 23 Stepping 10, GenuineIntel 
> PROCESSOR_LEVEL 6 
> PROCESSOR_REVISION

[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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

--
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-13043) Test Results Trend graph missing intermittently

2012-03-19 Thread jesse.ja...@hotmail.com (JIRA)


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

Jesse Jacob commented on JENKINS-13043:
---

Yes, that's the problem. I was able to repro using the steps in your comment--I 
can disbale and re-enable it just by saving with no changes on the project 
config. Thanks for the workaround!!

> Test Results Trend graph missing intermittently
> ---
>
> Key: JENKINS-13043
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13043
> Project: Jenkins
>  Issue Type: Bug
>  Components: nunit
>Affects Versions: current
> Environment: Windows 2008R2 running Jenkins as a service. This isn't 
> an error, it's more of a bad state, so there's no stack trace to show. Here's 
> the /systemInfo dump:
> Name   Value
> awt.toolkit sun.awt.windows.WToolkit 
> executable-war C:\Apps\Jenkins\jenkins.war 
> file.encoding Cp1252 
> file.encoding.pkg sun.io 
> file.separator \ 
> hudson.diyChunking true 
> hudson.lifecycle hudson.lifecycle.WindowsServiceLifecycle 
> java.awt.graphicsenv sun.awt.Win32GraphicsEnvironment 
> java.awt.headless true 
> java.awt.printerjob sun.awt.windows.WPrinterJob 
> java.class.path C:\Apps\Jenkins\jenkins.war 
> java.class.version 50.0 
> java.endorsed.dirs C:\Apps\Jenkins\jre\lib\endorsed 
> java.ext.dirs C:\Apps\Jenkins\jre\lib\ext;C:\Windows\Sun\Java\lib\ext 
> java.home C:\Apps\Jenkins\jre 
> java.io.tmpdir C:\Windows\TEMP\ 
> java.library.path 
> C:\Apps\Jenkins\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\csvn\bin\;C:\csvn\Python25\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program
>  Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft 
> SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL 
> Server\100\DTS\Binn\;c:\Program Files (x86)\Microsoft SQL 
> Server\100\Tools\Binn\VSShell\Common7\IDE\;c:\Program Files (x86)\Microsoft 
> SQL Server\100\DTS\Binn\;C:\Program Files\NCover\;C:\Program Files\Microsoft 
> Windows Performance Toolkit\;c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET 
> Web Pages\v1.0\;;. 
> java.runtime.name Java(TM) SE Runtime Environment 
> java.runtime.version 1.6.0_26-b03 
> java.specification.name Java Platform API Specification 
> java.specification.vendor Sun Microsystems Inc. 
> java.specification.version 1.6 
> java.vendor Sun Microsystems Inc. 
> java.vendor.url http://java.sun.com/ 
> java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi 
> java.version 1.6.0_26 
> java.vm.info mixed mode 
> java.vm.name Java HotSpot(TM) Client VM 
> java.vm.specification.name Java Virtual Machine Specification 
> java.vm.specification.vendor Sun Microsystems Inc. 
> java.vm.specification.version 1.0 
> java.vm.vendor Sun Microsystems Inc. 
> java.vm.version 20.1-b02 
> line.separator  
> mail.smtp.sendpartial true 
> mail.smtps.sendpartial true 
> os.arch x86 
> os.name Windows Server 2008 R2 
> os.version 6.1 
> path.separator ; 
> sun.arch.data.model 32 
> sun.boot.class.path 
> C:\Apps\Jenkins\jre\lib\resources.jar;C:\Apps\Jenkins\jre\lib\rt.jar;C:\Apps\Jenkins\jre\lib\sunrsasign.jar;C:\Apps\Jenkins\jre\lib\jsse.jar;C:\Apps\Jenkins\jre\lib\jce.jar;C:\Apps\Jenkins\jre\lib\charsets.jar;C:\Apps\Jenkins\jre\lib\modules\jdk.boot.jar;C:\Apps\Jenkins\jre\classes
>  
> sun.boot.library.path C:\Apps\Jenkins\jre\bin 
> sun.cpu.endian little 
> sun.cpu.isalist pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 
> sun.desktop windows 
> sun.io.unicode.encoding UnicodeLittle 
> sun.java.command C:\Apps\Jenkins\jenkins.war --httpPort=8080 
> sun.java.launcher SUN_STANDARD 
> sun.jnu.encoding Cp1252 
> sun.management.compiler HotSpot Client Compiler 
> sun.os.patch.level Service Pack 1 
> svnkit.http.methods Digest,Basic,NTLM,Negotiate 
> svnkit.ssh2.persistent false 
> user.country US 
> user.dir C:\Windows\system32 
> user.home C:\ 
> user.language en 
> user.name $ 
> user.timezone America/Chicago 
> user.variant  
> Environment Variables
> Name  ↓ Value
> ALLUSERSPROFILE C:\ProgramData 
> APPDATA C:\Windows\system32\config\systemprofile\AppData\Roaming 
> APR_ICONV1_PATH C:\csvn\bin\iconv\ 
> BASE C:\Apps\Jenkins 
> COMPUTERNAME 28SVMSVNCI051 
> ComSpec C:\Windows\system32\cmd.exe 
> CommonProgramFiles C:\Program Files (x86)\Common Files 
> CommonProgramFiles(x86) C:\Program Files (x86)\Common Files 
> CommonProgramW6432 C:\Program Files\Common Files 
> FP_NO_HOST_CHECK NO 
> JAVA_HOME C:\Program Files (x86)\Java\jdk1.6.0_27 
> JENKINS_HOME C:\Apps\Jenkins 
> LOCALAPPDATA C:\Windows\system32\config\systemprofile\AppData\Local 
> NUMBER_OF_PROCESSORS 2 
> OS Windows_NT 
> PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC 
> PROCESSOR_ARCHITECTURE x86 
> PROCE

[JIRA] (JENKINS-13146) Job config's "Execute concurrent builds if necessary" label could be clearer

2012-03-19 Thread w...@cloudera.com (JIRA)

Will McQueen created JENKINS-13146:
--

 Summary: Job config's "Execute concurrent builds if necessary" 
label could be clearer
 Key: JENKINS-13146
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13146
 Project: Jenkins
  Issue Type: Improvement
  Components: throttle-concurrents
Affects Versions: current
 Environment: CentOS 6.2 64-bit
Reporter: Will McQueen
Assignee: abayer
Priority: Minor
 Fix For: current


"Execute concurrent builds if necessary" label could be clearer. It's not 
immediately obvious to me what "if necessary" means. Enabling this option means 
that concurrent builds are allowed, either on the same slave node or across 
multiple slave nodes (subject to the restrictions of the TCB, or Throttle 
Concurrent Builds, plugin if enabled), correct? So maybe a better name for the 
option would be:
 "Allow concurrent builds"
...or...
 "Allow execution of concurrent builds"

--
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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=160426#comment-160426
 ] 

Steve Eckhardt commented on JENKINS-11641:
--

 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-tabpanel&focusedCommentId=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.(Channel.java:408)
at hudson.remoting.Channel.(Channel.java:366)
at hudson.remoting.Channel.(Channel.java:327)
at hudson.remoting.Channel.(Channel.java:323)
at hudson.remoting.Channel.(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-12660) Fail to start the windows service when trying to launch slave node


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

Christian Höltje commented on JENKINS-12660:


So what I did was add the Machine-Name part to the user names:

Launch method: Let Jenkins control this Windows slave as a Windows service
  Administrator user name: .\Administrator
  Password: ***
  Host:
  Run service as: Log on using a different account
User name: .\Builder
Password: ***

> Fail to start the windows service when trying to launch slave node
> --
>
> Key: JENKINS-12660
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12660
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave
>Affects Versions: current
> Environment: Master : Redhat 5
> Slave Node : Win7 x64
>Reporter: Rico ZHANG
>Assignee: Kohsuke Kawaguchi
>
> We used to be able to launch the slave node successfully, but it did not work 
> since we upgraded the jenkins to latest version (1.449)
> It doesn't dump any exception to the console, but I captured the output:
> {noformat}
> Connecting to 192.168.160.62
> Checking if Java exists
> java full version "1.7.0-b147"
> Installing the Jenkins slave service
> Copying jenkins-slave.exe
> Copying slave.jar
> Copying jenkins-slave.xml
> Registering the service
> ERROR: Failed to create a service: Status Invalid Service Account
> ...
> {noformat}

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

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

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

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


[ 
https://issues.jenkins-ci.org/browse/JENKINS-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
> My URL\2
> 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:
> My URL\2
> 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


 [ 
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


 [ 
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-6296) Remote API /computer/api/xml fails when the offlinecause is an EOFException

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


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

evernat resolved JENKINS-6296.
--

Resolution: Incomplete

No response from the reporter, so closing as incomplete.

> Remote API /computer/api/xml fails when the offlinecause is an EOFException
> ---
>
> Key: JENKINS-6296
> URL: https://issues.jenkins-ci.org/browse/JENKINS-6296
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Reporter: roxspring
>
> [17:33] <@mindless> roxspring: do you think the EOFException was contained 
> within the OfflineCause ?
> [17:36] <@mindless> roxspring: yeah, I see 
> OfflineCause.ChannelTermination.cause is @Exported
> [17:36] <@mindless> kohsuke: is @Exported on Exception bad?  it's not an 
> @ExportedBean ..
> [17:36] <@kohsuke> I don't think it's bad, but if the bean itself isn't 
> exported, it will have no effect.
> [17:37] <@mindless> kohsuke: http://hudson.pastebin.com/GQsLWw68
> [17:37] <@mindless> I could move @Exported to getShortDescription instead.. 
> returns cause.toString()
> [17:38] <@kohsuke> I think exposing structuerd data is a good thing
> [17:38] <@kohsuke> So the cause field is an Exception type?
> [17:38] <@mindless> yes
> [17:39] <@kohsuke> Maybe requiring the class to be marked was not a good idea
> [17:40] <@kohsuke> perhaps we should have just exported whatever properties 
> annotated with @Exported
> [17:40] <@mindless> it is annotated with @Exported
> [17:40] <@mindless> @Exported public final Exception cause;
> [17:40] <@kohsuke> but not the value referenced by the cause field.
> [17:40] <@mindless> you've lost me
> [17:41] <@kohsuke> The error is saying that the actual value, an instance of 
> EOFException, is not annotated with @ExportedBean
> [17:41] <@kohsuke> but if the semantics is such that no classes need to be 
> annotated by @ExportedBean, and if we just write out whatever @Exported 
> properties,
> [17:41] <@kohsuke> we'd just get  without an error
> [17:41] <@mindless> oh
> [17:41] <@kohsuke> because EOFException doesn't have any @Exported field
> [17:42] <@kohsuke> Or I suppose I could treat a value without @ExportedBean 
> as if it were null?
> [17:42] <@kohsuke> instead of a hard error
> [17:42] <@kohsuke> or it could be a switch like 
> @Exported(ignoreUnexportable=true)
> [17:43] <@kohsuke> Can you file a ticket for this?
> [17:43] <@mindless> roxspring: ^
> {noformat}
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.GeneratedMethodAccessor222.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:169)
>   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:75)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:519)
>   at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:145)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:519)
>   at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:145)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:519)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:435)
>   at org.kohsuke.stapler.Stapler.service(Stapler.java:123)
>   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.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
>   at

[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-tabpanel&focusedCommentId=160431#comment-160431
 ] 

suresh kukalakuntla commented on JENKINS-13119:
---

Greg,
I am able to successfully run the groovy script that serves my purpose. I 
really appreciate your help and time. You are very responsive and quick:)


Below is the log. MODULE_NAME is provided by user when performing build.


[EnvInject] - Evaluation the following Groovy script content: 
if(MODULE_NAME.equals('ACCT'))
{ 
def map = ["MODULE_HOME": "SSP-AM"] 

return map; 
}

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

return map; 
}


Building in workspace /usr/J2EE/JENKINS/jobs/TEST_GROOVY/workspace
[workspace] $ /bin/sh -xe /tmp/hudson50466.sh
+ echo MODULE_NAME:FPD
MODULE_NAME:FPD
+ echo MODULE_HOME:SSP-FPD
MODULE_HOME:SSP-FPD
Finished: SUCCESS

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

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

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


[ 
https://issues.jenkins-ci.org/browse/JENKINS-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


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

Ross Rowe commented on JENKINS-7830:


Hi, the latest version of the plugin (v1.11) should support this.  The host 
name and port will be stored in the SELENIUM_HOST and SELENIUM_PORT environment 
variables.  They default to 'localhost' and '' respectively - the port will 
default to 4445 if Sauce Connect is enabled.  These values can be overriden via 
the 'Advanced' options on the Sauce OnDemand configuration settings for a Job.

Let me know if you have any problems, or if you need any further information.

Cheers,

Ross

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


 [ 
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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
>  testId="3509a64f-6214-eb24-6628-bd431f93997c" 
> testName="TestcaseWcdmaTxIntermod_5_12__FDD9" computerName="1SP1-SLAVE2" 
> testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="NotExecuted" 
> testListId="8c84fa94-04c1-424b-9868-57a2d4851a1d" 
> relativeResultsDirectory="88518b81-226a-4fe9-9896-774a00c13e8e">
> 
> The transformation in the junitResult.xml file:
>   
>   NaN 
>   ConformanceWcdmaCompleteTest.BandSpecificTests 
>   TestcaseWcdmaTxIntermod_5_12__FDD9 
>   false 
>   0 
>   

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

[JIRA] (JENKINS-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:
>  testId="3509a64f-6214-eb24-6628-bd431f93997c" 
> testName="TestcaseWcdmaTxIntermod_5_12__FDD9" computerName="1SP1-SLAVE2" 
> testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="NotExecuted" 
> testListId="8c84fa94-04c1-424b-9868-57a2d4851a1d" 
> relativeResultsDirectory="88518b81-226a-4fe9-9896-774a00c13e8e">
> 
> The transformation in the junitResult.xml file:
>   
>   NaN 
>   ConformanceWcdmaCompleteTest.BandSpecificTests 
>   TestcaseWcdmaTxIntermod_5_12__FDD9 
>   false 
>   0 
>   

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

[JIRA] (JENKINS-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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. :)

--
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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 resolved JENKINS-11248.
-

Fix Version/s: current
   Resolution: Fixed

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

[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  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(Redep

[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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.(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(ClassicPluginStr

[JIRA] (JENKINS-8152) LDAP config error


[ 
https://issues.jenkins-ci.org/browse/JENKINS-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.tryInv

[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-tabpanel&focusedCommentId=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.(FileInputStream.java:121)
>   at java.io.FileInputStream.(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-tabpanel&focusedCommentId=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.(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