date:20120514

Stephan Pauxberger created JENKINS-13758:


 Summary: Incrememntal Builds: If a build is aborted right after a 
failed one, not all necessary modules are build
 Key: JENKINS-13758
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13758
 Project: Jenkins
  Issue Type: Bug
  Components: maven
 Environment: Jenkins 1.443, Linux, 64bit
Reporter: Stephan Pauxberger


This is related to JENKINS-5764.

We had the following scenario:

{{{
A-B-C (All Modules)
   X-Y
}}}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)


--
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-13758) Incrememntal Builds: If a build is aborted right after a failed one, not all necessary modules are build


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

Stephan Pauxberger updated JENKINS-13758:
-

Description: 
This is related to JENKINS-5764.

We had the following scenario:

{code}
A-B-C (All Modules)
   X-Y
{code}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)


  was:
This is related to JENKINS-5764.

We had the following scenario:

{{{
A-B-C (All Modules)
   X-Y
}}}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)



 Incrememntal Builds: If a build is aborted right after a failed one, not all 
 necessary modules are build
 

 Key: JENKINS-13758
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13758
 Project: Jenkins
  Issue Type: Bug
  Components: maven
 Environment: Jenkins 1.443, Linux, 64bit
Reporter: Stephan Pauxberger

 This is related to JENKINS-5764.
 We had the following scenario:
 {code}
 A-B-C (All Modules)
X-Y
 {code}
 Now, we introduce a change in A which breaks C (changed an interface in our 
 case). (#1)
 Now, something completely different is changed in X, which additionally 
 breaks Y(#2)
 Since the last build failed, A,B,C are built as well. Before the build 
 reaches C, it already fails due to failure of Y. In that moment, the 
 developer realizes a mistake and aborts the build.
 Now he fixes his error in X,Y and commits. (#3)
 Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
 to build A,B,C as well as X,Y.
 The next time someone changes something in C (no code, in our case), the 
 build suddenly fails (two days after the bad commit!) (#10)
 Proposed solutions:
 Easiest, but most expansive:
 After an aborted build, always do a full build (not incremental)
 Better solution:
 For a new build:
 - The list of modules to build includes all modules changed since last commit
 - go back in history until (not including) the last successful build, for all 
 builds that are NOT successful, include those run's changed

[JIRA] (JENKINS-13757) Unable to add or enable Email-ext plugin in jenkins 1.463.

2012-05-14 Thread s.sog...@gmail.com (JIRA)


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

sogabe resolved JENKINS-13757.
--

Resolution: Duplicate

duplicate of JENKINS-13737

 Unable to add or enable Email-ext plugin in jenkins 1.463.
 --

 Key: JENKINS-13757
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13757
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: I have promoted from 1.462 to 1.463 but i am unable to 
 add plugin Email-ext and its very urgent to get this resolve
Reporter: amit anand
Priority: Blocker



--
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-13759) Baseline template that support local variables

2012-05-14 Thread jbrej...@praqma.net (JIRA)

Jens  Brejner created JENKINS-13759:
---

 Summary: Baseline template that support local variables
 Key: JENKINS-13759
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13759
 Project: Jenkins
  Issue Type: Improvement
  Components: clearcase-ucm
Affects Versions: current
 Environment: Windows
Reporter: Jens  Brejner


Baseline template that support local variables, meanning the template can 
utilize environment variables that are local to the specific build

--
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-13759) Baseline template that support local variables

2012-05-14 Thread jbrej...@praqma.net (JIRA)


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

Jens  Brejner resolved JENKINS-13759.
-

  Assignee: Jens  Brejner
Resolution: Fixed

Already fixed, we needed the proxy case

 Baseline template that support local variables
 --

 Key: JENKINS-13759
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13759
 Project: Jenkins
  Issue Type: Improvement
  Components: clearcase-ucm
Affects Versions: current
 Environment: Windows
Reporter: Jens  Brejner
Assignee: Jens  Brejner

 Baseline template that support local variables, meanning the template can 
 utilize environment variables that are local to the specific build

--
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-13758) Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build


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

Stephan Pauxberger updated JENKINS-13758:
-

Summary: Incremental Builds: If a build is aborted right after a failed 
one, not all necessary modules are build  (was: Incrememntal Builds: If a build 
is aborted right after a failed one, not all necessary modules are build)
Description: 
This is related to JENKINS-5764.

We had the following scenario:

{code}
A-B-C (All Modules)
   X-Y
{code}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)

UPDATE: The better solution above is already implemented (except for this 
bug). I will look further into the code.


  was:
This is related to JENKINS-5764.

We had the following scenario:

{code}
A-B-C (All Modules)
   X-Y
{code}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)



 Incremental Builds: If a build is aborted right after a failed one, not all 
 necessary modules are build
 ---

 Key: JENKINS-13758
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13758
 Project: Jenkins
  Issue Type: Bug
  Components: maven
 Environment: Jenkins 1.443, Linux, 64bit
Reporter: Stephan Pauxberger

 This is related to JENKINS-5764.
 We had the following scenario:
 {code}
 A-B-C (All Modules)
X-Y
 {code}
 Now, we introduce a change in A which breaks C (changed an interface in our 
 case). (#1)
 Now, something completely different is changed in X, which additionally 
 breaks Y(#2)
 Since the last build failed, A,B,C are built as well. Before the build 
 reaches C, it already fails due to failure of Y. In that moment, the 
 developer realizes a mistake and aborts the build.
 Now he fixes his error in X,Y and commits. (#3)
 Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
 to build A,B,C as well as X,Y.
 The next time someone changes something in C (no code, in our case), the 
 build suddenly fails (two days after the bad commit!) (#10)
 Proposed solutions:

[JIRA] (JENKINS-13611) Misleading error leads to slave disconnecting from master


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

Lars Kruse commented on JENKINS-13611:
--

Hi Julian

The problem with the new GUI in Jenkins is apparently a problem for quite a lot 
of the plugins in the community right now - and we will also fix this issue in 
due time. Right now we are very concerned with not-crashing-the-slaves when 
something unforeseen happens (missing licenses, missing qaw ...and we have even 
seen this phenomena ourselves on linux when running jenkins as a service and 
the QAxxx environment variables aren't loaded from the .bash_profile).

IN all these occasion the plugin should fail gracefully with an informative 
error message of what is wrong.

What actually does seem to work is (as you are also hinting in your own 
description) when both Jenkins master and slave is running as user processes 
(e.g master is started using java -jar jenkins.war and the slaves are started 
using the .jnlp interface) everything works fine - also the nice informative 
error messages. 

However, we do realize, that we can not allow ourselves the luxury to 
anticipate that all Jenkins environments out there are run like this.
We have created quite a few Plugins, but we must admit, that the PRQA one is 
the only one, so far, where we have seen such significant differences in 
behavior, dependent on how the jenkins instance is started.

The licence issues are being scrutinized - they do give us grey hair.

But I can assure you, that we're in red-alert and we are working on these 
issues as we speak.

We expect to have a new release ready within very short.

 Misleading error leads to slave disconnecting from master
 -

 Key: JENKINS-13611
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13611
 Project: Jenkins
  Issue Type: Bug
  Components: prqa
Affects Versions: current
 Environment: Jenkins 1.441, Windows 7, QAC-7.2F
Reporter: Julian Requejo
Assignee: Mads Nielsen

 I'm having some issues running the PQRA Plugin. The 
 [documentation|https://wiki.jenkins-ci.org/display/JENKINS/PRQA+Plugin] is a 
 bit strange. To start with, the screenshot shows a report type quality, 
 even though it says that currently only compliance is available. Then it also 
 says that a tool qaw must be installed, which I don't have anywhere in my 
 installation files. In any case, here is the problem: the plugin seems to not 
 find this qaw tool, and it produces an error that disconnects my slave agent 
 from the master.
 Started by user X X, xx.xx...@xxx.xx
 Building remotely on Legoland
 Updating https://xxx/
 At revision 1292
 Updating https://xxx/
 At revision 1292
 Updating https://xxx/
 At revision 1292
 no change for Updating https://xxx/ since the 
 previous build
 no change for Updating https://xxx/ since the 
 previous build
 no change for Updating https://xxx/ since the 
 previous build
 This job will try to create a report with the following selected parameters:
 QAR selected project file:Sources//QAC.prj
 QAR selected product: QAC
 QAR selected report type: Compliance
 Beginning report generation with the following command:
  qaw QAC Sources//QAC.prj -maseq qar %Q %P+ %L+ -po 
 qar::report_type=Compliance\ Report -po qar::project_name=%J -po 
 qar::output_path=c:\_dev\jenkins-int\workspace\x\ QAC -po 
 qar::viewing_program=dummy -po qar::report_format=xhtml 
 ERROR: Publisher net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier aborted 
 due to exception
 hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.net.SocketException: Connection 
 reset
   at hudson.remoting.Request.call(Request.java:149)
   at hudson.remoting.Channel.call(Channel.java:681)
   at hudson.FilePath.act(FilePath.java:772)
   at hudson.FilePath.act(FilePath.java:765)
   at 
 net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier.perform(PRQANotifier.java:203)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:692)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:667)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:645)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:614)
   at hudson.model.Run.run(Run.java:1429)
   at

[JIRA] (JENKINS-13611) Misleading error leads to slave disconnecting from master


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

Lars Kruse commented on JENKINS-13611:
--

...Oh. I forgot to respond to your offer to post us logs! We might need them 
later, but for now we are perfectly able to reproduce these issues on our lab 
environment - so for now we're OK. But I might want to get back to you later 
;-) 

 Misleading error leads to slave disconnecting from master
 -

 Key: JENKINS-13611
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13611
 Project: Jenkins
  Issue Type: Bug
  Components: prqa
Affects Versions: current
 Environment: Jenkins 1.441, Windows 7, QAC-7.2F
Reporter: Julian Requejo
Assignee: Mads Nielsen

 I'm having some issues running the PQRA Plugin. The 
 [documentation|https://wiki.jenkins-ci.org/display/JENKINS/PRQA+Plugin] is a 
 bit strange. To start with, the screenshot shows a report type quality, 
 even though it says that currently only compliance is available. Then it also 
 says that a tool qaw must be installed, which I don't have anywhere in my 
 installation files. In any case, here is the problem: the plugin seems to not 
 find this qaw tool, and it produces an error that disconnects my slave agent 
 from the master.
 Started by user X X, xx.xx...@xxx.xx
 Building remotely on Legoland
 Updating https://xxx/
 At revision 1292
 Updating https://xxx/
 At revision 1292
 Updating https://xxx/
 At revision 1292
 no change for Updating https://xxx/ since the 
 previous build
 no change for Updating https://xxx/ since the 
 previous build
 no change for Updating https://xxx/ since the 
 previous build
 This job will try to create a report with the following selected parameters:
 QAR selected project file:Sources//QAC.prj
 QAR selected product: QAC
 QAR selected report type: Compliance
 Beginning report generation with the following command:
  qaw QAC Sources//QAC.prj -maseq qar %Q %P+ %L+ -po 
 qar::report_type=Compliance\ Report -po qar::project_name=%J -po 
 qar::output_path=c:\_dev\jenkins-int\workspace\x\ QAC -po 
 qar::viewing_program=dummy -po qar::report_format=xhtml 
 ERROR: Publisher net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier aborted 
 due to exception
 hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.net.SocketException: Connection 
 reset
   at hudson.remoting.Request.call(Request.java:149)
   at hudson.remoting.Channel.call(Channel.java:681)
   at hudson.FilePath.act(FilePath.java:772)
   at hudson.FilePath.act(FilePath.java:765)
   at 
 net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier.perform(PRQANotifier.java:203)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:692)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:667)
   at 
 hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:645)
   at hudson.model.Build$RunnerImpl.post2(Build.java:162)
   at 
 hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:614)
   at hudson.model.Run.run(Run.java:1429)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException: 
 Connection reset
   at hudson.remoting.Request.abort(Request.java:273)
   at hudson.remoting.Channel.terminate(Channel.java:732)
   at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139)
 Caused by: java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
   at 
 java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
   at 
 java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2542)
   at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
   at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109)
 Notifying upstream projects of job completion
 Finished:

[JIRA] (JENKINS-13760) Tag this build results in ERROR: Failed to tag, org.tmatesoft.svn.core.SVNException: svn: File not found: revision 555, path '/trunk/trunk'

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

Tom Fanning created JENKINS-13760:
-

 Summary: Tag this build results in ERROR: Failed to tag, 
org.tmatesoft.svn.core.SVNException: svn: File not found: revision 555, path 
'/trunk/trunk'
 Key: JENKINS-13760
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13760
 Project: Jenkins
  Issue Type: Bug
  Components: core
 Environment: Windows Server 2003 x86, Jenkins version=1.450, 
Subversion Plugin version=1.39
Reporter: Tom Fanning


When I click Tag this build then Tag, I get the following stack trace:

Build #234

Tagging is in progress:

Tagging https://ccr/svn/Our_Product/trunk (rev.555) to 
https://ccr/svn/Our_Product/tags/test
ERROR: Failed to tag
org.tmatesoft.svn.core.SVNException: svn: File not found: revision 555, path 
'/trunk/trunk'
svn: '/svn/Our_Product/!svn/bc/555/trunk' path not found: 404 Not Found 
(https://ccr)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.doGetMergeInfo(DAVRepository.java:1232)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getMergeInfoImpl(DAVRepository.java:1127)
at 
org.tmatesoft.svn.core.io.SVNRepository.getMergeInfo(SVNRepository.java:2541)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.getReposMergeInfo(SVNBasicClient.java:608)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.calculateTargetMergeInfo(SVNCopyDriver.java:1711)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.copyReposToRepos(SVNCopyDriver.java:318)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.setupCopy(SVNCopyDriver.java:629)
at 
org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:426)
at 
hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:261)
at hudson.model.TaskThread.run(TaskThread.java:127)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: File not found: 
revision 555, path '/trunk/trunk'
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.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:99)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown 
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
 Source)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:776)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:741)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readError(HTTPConnection.java:222)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:290)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
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.doReport(DAVConnection.java:283)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:274)
at

[JIRA] (JENKINS-13760) Tag this build results in ERROR: Failed to tag, org.tmatesoft.svn.core.SVNException: svn: File not found: revision 555, path '/trunk/trunk'

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


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

Tom Fanning updated JENKINS-13760:
--

Description: 
When I click Tag this build then Tag, I get the following stack trace:

Build #234

Tagging is in progress:

Tagging https://ccr/svn/Our_Product/trunk (rev.555) to 
https://ccr/svn/Our_Product/tags/test
ERROR: Failed to tag
org.tmatesoft.svn.core.SVNException: svn: File not found: revision 555, path 
'/trunk/trunk'
svn: '/svn/Our_Product/!svn/bc/555/trunk' path not found: 404 Not Found 
(https://ccr)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.doGetMergeInfo(DAVRepository.java:1232)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getMergeInfoImpl(DAVRepository.java:1127)
at 
org.tmatesoft.svn.core.io.SVNRepository.getMergeInfo(SVNRepository.java:2541)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.getReposMergeInfo(SVNBasicClient.java:608)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.calculateTargetMergeInfo(SVNCopyDriver.java:1711)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.copyReposToRepos(SVNCopyDriver.java:318)
at 
org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.setupCopy(SVNCopyDriver.java:629)
at 
org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:426)
at 
hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:261)
at hudson.model.TaskThread.run(TaskThread.java:127)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: File not found: 
revision 555, path '/trunk/trunk'
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.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:99)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
 Source)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown 
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown 
Source)
at 
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
 Source)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:776)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:741)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readError(HTTPConnection.java:222)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:290)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
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.doReport(DAVConnection.java:283)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:274)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.doGetMergeInfo(DAVRepository.java:1226)
... 9 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: 
'/svn/Our_Product/!svn/bc/555/trunk' path not found: 404 Not Found (https://ccr)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
at

[JIRA] (JENKINS-13758) Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build


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

Stephan Pauxberger updated JENKINS-13758:
-

Description: 
This is related to JENKINS-5764.

We had the following scenario:

{code}
A-B-C (All Modules)
   X-Y
{code}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)



  was:
This is related to JENKINS-5764.

We had the following scenario:

{code}
A-B-C (All Modules)
   X-Y
{code}

Now, we introduce a change in A which breaks C (changed an interface in our 
case). (#1)

Now, something completely different is changed in X, which additionally breaks 
Y(#2)

Since the last build failed, A,B,C are built as well. Before the build reaches 
C, it already fails due to failure of Y. In that moment, the developer realizes 
a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build 
suddenly fails (two days after the bad commit!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all 
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full 
build.

That way, the problem above would not happen, because commit #3 would result in 
a previously affected modules since the last successful build to build rebuild 
as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like 
JENKINS-5121)

UPDATE: The better solution above is already implemented (except for this 
bug). I will look further into the code.



 Incremental Builds: If a build is aborted right after a failed one, not all 
 necessary modules are build
 ---

 Key: JENKINS-13758
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13758
 Project: Jenkins
  Issue Type: Bug
  Components: maven
 Environment: Jenkins 1.443, Linux, 64bit
Reporter: Stephan Pauxberger

 This is related to JENKINS-5764.
 We had the following scenario:
 {code}
 A-B-C (All Modules)
X-Y
 {code}
 Now, we introduce a change in A which breaks C (changed an interface in our 
 case). (#1)
 Now, something completely different is changed in X, which additionally 
 breaks Y(#2)
 Since the last build failed, A,B,C are built as well. Before the build 
 reaches C, it already fails due to failure of Y. In that moment, the 
 developer realizes a mistake and aborts the build.
 Now he fixes his error in X,Y and commits. (#3)
 Incremental build only builds X,Y, i.e. the build succeeds. Expected would be 
 to build A,B,C as well as X,Y.
 The next time someone changes something in C (no code, in our case), the 
 build suddenly fails (two days after the bad commit!) (#10)
 Proposed solutions:
 Easiest, but most expansive:
 After an aborted build, always do a full build (not incremental)
 Better solution:
 For a new build:
 - The list of modules to build includes all modules changed since last commit
 - go back in history

[JIRA] (JENKINS-13761) PRAQ plugin disconnects slaves on Linux when tools aren't installed correctly

Lars Kruse created JENKINS-13761:


 Summary: PRAQ plugin disconnects slaves on Linux when tools aren't 
installed correctly
 Key: JENKINS-13761
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13761
 Project: Jenkins
  Issue Type: Improvement
  Components: prqa
 Environment: Linux (Seen and reproduced on Fedora 16 - 64bit) - but 
probably affects all Linux version
Reporter: Lars Kruse
Assignee: Lars Kruse


This issue is reported during beta test (on version PRQA plugin version 1.0.1), 
and reported by the tester like this:

Quote begin
We have done some tests on Linux - using the plugin causes Jenkins to crash! We 
don't quite understand this - there was no information in the build log files.
However, we were able to run the command to analyse and generate the report as 
a normal build step as a shell command. We used exactly the same command as the 
for Windows:
-  Obviously we used forward slashes in the path to the project

-   I was wrong about qaw being called qaw.pl - it is called qaw on 
Linux

-  qar is called qar.pl on Linux - but we added a symbolic link 
'qar-qar.pl' in the qar binary directory. This seems the easiest solution (and 
perhaps we might include this link in future versions of war)
quote end




--
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-13762) Subversion authentication module doesn't handle invalid cert file or wrong cert password for https-client-certificates correctly

Marco Borm created JENKINS-13762:


 Summary: Subversion authentication module doesn't handle invalid 
cert file or wrong cert password for https-client-certificates correctly
 Key: JENKINS-13762
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13762
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Windows Server 2003, Java 1.6.0.31, Jenkins 1.463, 
Subversion Plugin 1.39
Reporter: Marco Borm
 Attachments: emptycertificate.png, subversionException.txt

The subversion authentication module accepts any file as certificate and 
anything as password. A failure always results in the same not helpful 
exception SSL handshake failed: 'Received fatal alert: handshake_failure' 
after the subversion client send a empty client certificate send to the server 
on the TLS connection. I am not sure if is allowed to send a empty client 
certificate message to the server.

Due the complexity of the software chain and configuration parameters used for 
HTTPS authentication, it is very annoying to find the real problem if no 
component returns a usable error message.

The expected behavior is to validate the input parameters and do not try to 
establish a connection with obvious invalid parameters.

--
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-13763) subversion authentication doesn't work on correct certificate parameters

Marco Borm created JENKINS-13763:


 Summary: subversion authentication doesn't work on correct 
certificate parameters
 Key: JENKINS-13763
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13763
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Windows Server 2003, Java 1.6.0.31, Jenkins 1.463, 
Subversion Plugin 1.39
Reporter: Marco Borm
 Attachments: emptycertificate.png, subversionException.txt

The subversion authentication module accepts any file as certificate and 
anything as password. A failure always results in the same not helpful 
exception SSL handshake failed: 'Received fatal alert: handshake_failure' 
after the subversion client send a empty client certificate send to the server 
on the TLS connection. I am not sure if is allowed to send a empty client 
certificate message to the server.

Due the complexity of the software chain and configuration parameters used for 
HTTPS authentication, it is very annoying to find the real problem if no 
component returns a usable error message.

The expected behavior is to validate the input parameters and do not try to 
establish a connection with obvious invalid parameters.

--
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-13763) subversion https-client authentication doesn't work with correct parameters

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

Marco Borm updated JENKINS-13763:
-

Summary: subversion https-client authentication doesn't work with
correct parameters (was: subversion authentication doesn't work on correct
certificate parameters)
Attachment: emptycertificate.png
subversionException.txt
Description:
The subversion authentication module currently doesn't work, even with correct
parameters. The behavior is identical to the already created bug due the not
validating input parameters. The exception gives no hint what the problem /
reason is.

The authentication works perfectly if the same certificate (p12) file and the
same password is configured manually within the subversion Application
Data\Subversion\servers file.

was:
The subversion authentication module accepts any file as certificate and
anything as password. A failure always results in the same not helpful
exception SSL handshake failed: 'Received fatal alert: handshake_failure'
after the subversion client send a empty client certificate send to the server
on the TLS connection. I am not sure if is allowed to send a empty client
certificate message to the server.

Due the complexity of the software chain and configuration parameters used for
HTTPS authentication, it is very annoying to find the real problem if no
component returns a usable error message.

The expected behavior is to validate the input parameters and do not try to
establish a connection with obvious invalid parameters.

subversion https-client authentication doesn't work with correct parameters
---

Key: JENKINS-13763
URL: https://issues.jenkins-ci.org/browse/JENKINS-13763
Project: Jenkins
Issue Type: Bug
Components: subversion
Affects Versions: current
Environment: Windows Server 2003, Java 1.6.0.31, Jenkins 1.463,
Subversion Plugin 1.39
Reporter: Marco Borm
Attachments: emptycertificate.png, emptycertificate.png,
subversionException.txt, subversionException.txt

The subversion authentication module currently doesn't work, even with
correct parameters. The behavior is identical to the already created bug due
the not validating input parameters. The exception gives no hint what the
problem / reason is.
The authentication works perfectly if the same certificate (p12) file and the
same password is configured manually within the subversion Application
Data\Subversion\servers file.

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

[JIRA] (JENKINS-13761) PRAQ plugin disconnects slaves on Linux when tools aren't installed correctly


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

Lars Kruse commented on JENKINS-13761:
--

The plugin version s 1.0.x aren't compliant with windows. But on the other 
hand, disconnecting the slave when something goes wrong is not acceptable.

This is also related to https://issues.jenkins-ci.org/browse/JENKINS-13611

 PRAQ plugin disconnects slaves on Linux when tools aren't installed correctly
 -

 Key: JENKINS-13761
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13761
 Project: Jenkins
  Issue Type: Improvement
  Components: prqa
 Environment: Linux (Seen and reproduced on Fedora 16 - 64bit) - but 
 probably affects all Linux version
Reporter: Lars Kruse
Assignee: Lars Kruse
  Labels: Praqma

 This issue is reported during beta test (on version PRQA plugin version 
 1.0.1), and reported by the tester like this:
 Quote begin
 We have done some tests on Linux - using the plugin causes Jenkins to crash! 
 We don't quite understand this - there was no information in the build log 
 files.
 However, we were able to run the command to analyse and generate the report 
 as a normal build step as a shell command. We used exactly the same command 
 as the for Windows:
 -  Obviously we used forward slashes in the path to the project
 -   I was wrong about qaw being called qaw.pl - it is called qaw on 
 Linux
 -  qar is called qar.pl on Linux - but we added a symbolic link 
 'qar-qar.pl' in the qar binary directory. This seems the easiest solution 
 (and perhaps we might include this link in future versions of war)
 quote end

--
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-13642) Jenkins build log contains junk characters from Phing output

2012-05-14 Thread s.sog...@gmail.com (JIRA)


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

sogabe commented on JENKINS-13642:
--

Phing plugin has supported ConsoleNoteAnnotator since version 0.6. 
Junk character is escape sequence to display links.

 Jenkins build log contains junk characters from Phing output
 

 Key: JENKINS-13642
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13642
 Project: Jenkins
  Issue Type: Bug
  Components: phing
Affects Versions: current
 Environment: Ubuntu 10.04 LTS, Jenkins 1.461, Phing Plugin 0.11, 
 Phing 2.4.12
Reporter: Frank Koehl
Assignee: sogabe

 The build log generated by Jenkins is loaded with junk characters where 
 in/around log output coming from Phing.
 {code}JENKINS_HOME/jobs/[JOBNAME]/builds/[BUILDNUMBER]/log{code} 
 Sample output...
 {code}
 At revision 26
 looking for 
 '/var/lib/jenkins/jobs/JOBNAME/workspace/build/buildscripts/build.xml' ...
 use '/var/lib/jenkins/jobs/JOBNAME/workspace' as a working directory.
 [workspace] $ phing -buildfile 
 /var/lib/jenkins/jobs/JOBNAME/workspace/build/buildscripts/build.xml -logger 
 phing.listener.DefaultLogger
 Buildfile: 
 /var/lib/jenkins/jobs/JOBNAME/workspace/build/buildscripts/build.xml
 ^[[8mha:ZB+LCABb85aBtbiIQSejNKU4P0+vIKc0PTOvWK8gIzMvXS85P684PydVLwDEC0ksSk8t8csvSe1Zynx/wmzdSUwMDBVFDFJQrTDFzhAapJABAhhBCgsAxIr4amo=^[[0mname-of-project
   clean:
 ^[[8mha:ZB+LCABb85aBtbiIQSejNKU4P0+vIKc0PTOvWK8gIzMvXS85P684PydVLwDEC0ksSk8t8csvSe1Zynx/wmzdSUwMDBVFDFJQrTDFzhAapJABAhhBCgsAxIr4amo=^[[0mname-of-project
   prepare:
 [mkdir] Created dir: 
 /var/lib/jenkins/jobs/JOBNAME/workspace/artifacts/code-browser
 [mkdir] Created dir: 
 /var/lib/jenkins/jobs/JOBNAME/workspace/artifacts/logs
 [mkdir] Created dir: 
 /var/lib/jenkins/jobs/JOBNAME/workspace/artifacts/pdepend
 [mkdir] Created dir: 
 /var/lib/jenkins/jobs/JOBNAME/workspace/artifacts/phpdox
 ^[[8mha:ZB+LCABb85aBtbiIQSejNKU4P0+vIKc0PTOvWK8gIzMvXS85P684PydVLwDEC0ksSk8t8csvSe1Zynx/wmzdSUwMDBVFDFJQrTDFzhAapJABAhhBCgsAxIr4amo=^[[0mname-of-project
   phplint:
 ^[[8mha:ZB+LCABb85aBtbiIQSejNKU4P0+vIKc0PTOvWK8gIzMvXS85P684PydVLwDEC0ksSk8t8csvSe1Zynx/wmzdSUwMDBVFDFJQrTDFzhAapJABAhhBCgsAxIr4amo=^[[0mname-of-project
   build:
 ^[[8mha:ZR+LCABb85aBtbiIQTejNKU4P0+vIKc0PTOvWK8gIzMvXS85P684PydVLwDE8y8tSc7PTfXLL0k9c6yzJK01gpOJgaGiiEEKqhem2hlCgxQyQAAjSGEBAOPRMRpr^[[0mBUILD
  FINISHED
 Total time: 0.1892 seconds
 Finished: SUCCESS
 {code}
 I have already reviewed similar issue 
 [JENKINS-10034|https://issues.jenkins-ci.org/browse/JENKINS-10034]. The 
 excess characters are different, and I am using the Phing plugin, not a 
 command line call. Plus you can see that the plugin is using the *-logger 
 phing.listener.DefaultLogger* argument as expected.
 That being said, running the phing command raw from the command line does 
 produce coloring output that aligns with the junk output.

--
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-13764) CVS authentication failure while running rlog command (Windows master / Unix slave)

2012-05-14 Thread lkl...@java.net (JIRA)

lklock created JENKINS-13764:


 Summary: CVS authentication failure while running rlog command 
(Windows master / Unix slave)
 Key: JENKINS-13764
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13764
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
Affects Versions: current
 Environment: Jenkins 1.463
CVS Plugin 2.3
Master is running Windows, Slave is on Solaris
Reporter: lklock


I'm building on a Solaris slave trying to access a CVS repository over SSH 
connection
Private key location is set to $SSH_PRIVATE_KEY_DIR/id_rsa
and known hosts to $SSH_PRIVATE_KEY_DIR/known_hosts

On the slave, SSH_PRIVATE_KEY_DIR is set to:
/export/home/cxt2tst/.ssh

Checkout is done properly:
Building remotely on picard in workspace 
/export/home/cxt2tst/HUDSON/workspace/server.8.0
cvs update -d -P -r HEAD -D 14 May 2012 14:17:28 +0200 server.8.0 
cvs update: Updating server.8.0
cvs update: Updating server.8.0/configuration



but when it tries to get the ChangeLog, an exception is raised with the 
following stack trace
FATAL: CVS authentication failure while running rlog command
java.lang.RuntimeException: CVS authentication failure while running rlog 
command
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:530)
at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:414)
at hudson.scm.CVSSCM.checkout(CVSSCM.java:821)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: org.netbeans.lib.cvsclient.connection.AuthenticationException: SSH 
connection failed.
at 
org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:134)
at org.netbeans.lib.cvsclient.Client$1.run(Client.java:374)
at java.lang.Thread.run(Unknown Source)
Caused by: com.jcraft.jsch.JSchException: java.io.FileNotFoundException: 
\export\home\cxt2tst\.ssh\id_rsa (The system cannot find the path specified)
at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:98)
at com.jcraft.jsch.JSch.addIdentity(JSch.java:224)
at com.jcraft.jsch.JSch.addIdentity(JSch.java:218)
at 
org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:128)
... 2 more
Caused by: java.io.FileNotFoundException: \export\home\cxt2tst\.ssh\id_rsa (The 
system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(Unknown Source)
at java.io.FileInputStream.init(Unknown Source)
at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:83)
... 5 more


It seems it cannot find the file due to the use of wrong path separator 

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

[JIRA] (JENKINS-12423) Password masked by Mask Passwords are visible when using envinject plugin

2012-05-14 Thread smyau...@gmail.com (JIRA)


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

Natalia Naumova commented on JENKINS-12423:
---

Gregory, thank you very much for your quick help. 
Looking forward to try it when the new version of the plugin will be released. 

 Password masked by Mask Passwords are visible when using envinject plugin
 -

 Key: JENKINS-12423
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12423
 Project: Jenkins
  Issue Type: Bug
  Components: envinject, mask-passwords, perforce
 Environment: envinject1.9
 mask-passwords2.7.2
 Jenkins ver. 1.424.1
 Windows
 Perforce plugin 1.3.7
Reporter: Roger Myung
Assignee: Gregory Boissinot

 If I use the mask-passwords plugin to create a masked password, and also use 
 the envinject plugin to setup an environment, the masked password is visible 
 from the Injected Environment Variables link for each build.

--
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-13763) subversion https-client authentication doesn't work with correct parameters


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

Marco Borm commented on JENKINS-13763:
--

Unfortunately the workaround with the servers-file doesn't work under linux. 
I can checkout successfully using the plain svn tools using the sam user as 
jenkins, but jenkins itself fails with an exception. Due the problem that I 
can't store the authentication data within jenkins, we can't checkout using 
jenkins under linux now.

Exception:
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No 
credential to try. Authentication failed
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at 
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:223)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:426)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:406)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:302)
at 
sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282)
at 
sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629)
at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:546)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:945)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1190)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:657)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:108)
at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:238)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:168)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:385)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)
... 35 more
Caused by: svn: E200015: No credential to try. Authentication failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 56 more

 subversion https-client authentication doesn't work with correct parameters
 ---

 Key: JENKINS-13763
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13763
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Windows Server 2003, Java 1.6.0.31, Jenkins 1.463, 
 Subversion Plugin 1.39
Reporter: Marco Borm
 Attachments: emptycertificate.png, emptycertificate.png, 
 subversionException.txt, subversionException.txt


 The subversion authentication module currently doesn't work, even with 
 correct parameters. The behavior is identical to the already created bug due 
 the not validating input parameters. The exception gives no hint what the 
 problem / reason is.
 The authentication works perfectly if the same certificate (p12) file and the 
 same password is configured manually within the subversion Application 
 Data\Subversion\servers file.

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

[JIRA] (JENKINS-13758) Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build

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

Stephan Pauxberger commented on JENKINS-13758:
--

Created Pull Request #472, that should fix it.

I replaced UnbuiltModuleAction with a shorter and IMHO safer construct.

Each incremental build records its changedModules in a ChangedModuleAction.

When calculating the changed modules, last build's changedModules are added (if
last build was not successful).

The should solve all possible after-build actions problems (as mentioned in
related Issues) without the need for some specific workarounds.

For example: Now all modules that have been built (and not deployed) or MIGHT
have been built since last successful build are build again and deployed during
post-build deploy step.

Incremental Builds: If a build is aborted right after a failed one, not all
necessary modules are build
---

Key: JENKINS-13758
URL: https://issues.jenkins-ci.org/browse/JENKINS-13758
Project: Jenkins
Issue Type: Bug
Components: maven
Environment: Jenkins 1.443, Linux, 64bit
Reporter: Stephan Pauxberger

This is related to JENKINS-5764.
We had the following scenario:
{code}
A-B-C (All Modules)
X-Y
{code}
Now, we introduce a change in A which breaks C (changed an interface in our
case). (#1)
Now, something completely different is changed in X, which additionally
breaks Y(#2)
Since the last build failed, A,B,C are built as well. Before the build
reaches C, it already fails due to failure of Y. In that moment, the
developer realizes a mistake and aborts the build.
Now he fixes his error in X,Y and commits. (#3)
Incremental build only builds X,Y, i.e. the build succeeds. Expected would be
to build A,B,C as well as X,Y.
The next time someone changes something in C (no code, in our case), the
build suddenly fails (two days after the bad commit!) (#10)
Proposed solutions:
Easiest, but most expansive:
After an aborted build, always do a full build (not incremental)
Better solution:
For a new build:
- The list of modules to build includes all modules changed since last commit
- go back in history until (not including) the last successful build, for all
builds that are NOT successful, include those run's changed modules as well
- if there are no successful builds in the build history, always do a full
build.
That way, the problem above would not happen, because commit #3 would result
in a previously affected modules since the last successful build to build
rebuild as well (resulting in a breaking build for C).
Note that this bug should also affect a couple of other fixed bugs (like
JENKINS-5121)

[JIRA] (JENKINS-13763) subversion https-client authentication doesn't work with correct parameters


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

Marco Borm commented on JENKINS-13763:
--

Ok, the mistake was a missing password character. So the workaround works also 
under linux, but: The error message was wrong again. No credential to try - 
found credentials wrong

 subversion https-client authentication doesn't work with correct parameters
 ---

 Key: JENKINS-13763
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13763
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Windows Server 2003, Java 1.6.0.31, Jenkins 1.463, 
 Subversion Plugin 1.39
Reporter: Marco Borm
 Attachments: emptycertificate.png, emptycertificate.png, 
 subversionException.txt, subversionException.txt


 The subversion authentication module currently doesn't work, even with 
 correct parameters. The behavior is identical to the already created bug due 
 the not validating input parameters. The exception gives no hint what the 
 problem / reason is.
 The authentication works perfectly if the same certificate (p12) file and the 
 same password is configured manually within the subversion Application 
 Data\Subversion\servers file.

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

[JIRA] (JENKINS-12787) LOADING overlay does not go away on the Configure System page

2012-05-14 Thread lshat...@java.net (JIRA)


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

lshatzer commented on JENKINS-12787:


I recently went through and removed (from the file system) all disabled 
plugins, and this problem went away after I did that, and restarted. I'm not 
sure which plugin caused that.

 LOADING overlay does not go away on the Configure System page
 -

 Key: JENKINS-12787
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12787
 Project: Jenkins
  Issue Type: Bug
  Components: gui
Affects Versions: current
 Environment: Jenkins 
Reporter: Joshua Davis
Priority: Blocker
  Labels: gui, jenkins

 After navigating to Manage-Configure System, the LOADING overlay never goes 
 away.  It is impossible to save any configuration changes.
 EXPECTED:
 * You can save your global configuration.
 Here is the stack trace from Chrome's JS console:
 {code}
 Uncaught TypeError: Object #Object has no method 'findMatchingInput'
 (anonymous function)
 e.targetUrl hudson-behavior.js:338
 registerValidator hudson-behavior.js:343
  apply behavior.js:73
 (anonymous function) behavior.js:79
 Behaviour.applySubtree behavior.js:68
 Behaviour.applybehavior.js:54
 (anonymous function)behavior.js:49
 window.onload
 {code}

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

[JIRA] (JENKINS-13055) checkout error for org.tmatesoft.svn.core.SVNException: svn: REPORT /svn/hit71/!svn/vcc/default failed

2012-05-14 Thread madeline.g...@gmail.com (JIRA)


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

Maddy Goss edited comment on JENKINS-13055 at 5/14/12 1:59 PM:
---

I'm getting the same error in one of my checkouts (see below), after which I 
can't checkout due to a locked file. (also see below)

 initial error -
12:12:54  ERROR: Failed to check out http://my.repo.com/myproject/trunk/mymodule
12:12:54  org.tmatesoft.svn.core.SVNException: svn: REPORT 
/myproject/!svn/vcc/default failed
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:283)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1282)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:830)
12:12:54at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:564)
12:12:54at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:942)
12:12:54at 
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
12:12:54at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
12:12:54at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:788)
12:12:54at 
hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:769)
12:12:54at 
hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
12:12:54at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
12:12:54at hudson.remoting.UserRequest.perform(UserRequest.java:118)
12:12:54at hudson.remoting.UserRequest.perform(UserRequest.java:48)
12:12:54at hudson.remoting.Request$2.run(Request.java:287)
12:12:54at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
12:12:54at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
12:12:54at java.util.concurrent.FutureTask.run(Unknown Source)
12:12:54at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
12:12:54at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source)
12:12:54at java.lang.Thread.run(Unknown Source)
12:12:54  Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: REPORT 
/myproject/!svn/vcc/default failed
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146)
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
12:12:54... 23 more
12:12:54  Caused by: org.tmatesoft.svn.core.SVNException: svn: REPORT request 
failed on '/myproject/!svn/vcc/default'
12:12:54  svn: Processing REPORT request response failed: XML document 
structures must start and end within the same entity. 
(/myproject/!svn/vcc/default) 
12:12:54at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
12:12:54at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:662)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
12:12:54... 22 more
12:12:54  Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: REPORT 
request failed on '/myproject/!svn/vcc/default'
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:660)
12:12:54... 23 more
12:12:54  Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: Processing 
REPORT request response failed: XML document structures must start and end 
within the same entity. (/myproject/!svn/vcc/default) 
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181)
12:12:54at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:790)
12:12:54at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:741)
12:12:54

[JIRA] (JENKINS-13765) PTC Integrity Plugin - Restore Timestamp Not Working

2012-05-14 Thread udit.jhal...@westernunion.com (JIRA)

Udit Jhalani created JENKINS-13765:
--

 Summary: PTC Integrity Plugin - Restore Timestamp Not Working
 Key: JENKINS-13765
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13765
 Project: Jenkins
  Issue Type: Bug
  Components: integrity-plugin
Affects Versions: current
 Environment: Windows Server 2008 R2, 
Reporter: Udit Jhalani
Assignee: Cletus D'Souza
Priority: Blocker
 Fix For: current
 Attachments: 1.jpg, Source_Conf.jpg

The restore time stamp is not working for me when I poll source to get latest 
changes. Any help is appreciated! Let me know if any other information is 
required.

--
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-13766) Make sure filed issues on config-rotator component get to praqma support

2012-05-14 Thread b...@praqma.net (JIRA)

Bue Petersen created JENKINS-13766:
--

 Summary: Make sure filed issues on config-rotator component get to 
praqma support
 Key: JENKINS-13766
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13766
 Project: Jenkins
  Issue Type: Task
  Components: config-rotator
Affects Versions: current
Reporter: Bue Petersen
Assignee: Praqma Support
Priority: Trivial


It important we as developer of the plugin get all filed issues for our 
component. We will look into them.

--
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-13766) Make sure filed issues on config-rotator component get to praqma support

2012-05-14 Thread b...@praqma.net (JIRA)


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

Bue Petersen resolved JENKINS-13766.


Fix Version/s: current
   Resolution: Fixed

We are satisfied with the workflow as we get notified about the issues.

 Make sure filed issues on config-rotator component get to praqma support
 

 Key: JENKINS-13766
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13766
 Project: Jenkins
  Issue Type: Task
  Components: config-rotator
Affects Versions: current
Reporter: Bue Petersen
Assignee: Praqma Support
Priority: Trivial
 Fix For: current


 It important we as developer of the plugin get all filed issues for our 
 component. We will look into them.

--
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-13429) Nested views not showing up with just read perms for View

2012-05-14 Thread jos...@java.net (JIRA)


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

Jose Sa edited comment on JENKINS-13429 at 5/14/12 2:42 PM:


Upgraded from 1.456 (which had nested views of nested views showing ok) to 
1.462 and now it only shows the default All view and no nested views.
Had to revert and will have to stick with 1.458 until nested tabs can be 
visible again with anonymous view.read permission is working.

  was (Author: josesa):
Upgraded from 1.460 (which had nested views of nested views showing ok) to 
1.462 and now it only shows the default All view and no nested views.
  
 Nested views not showing up with just read perms for View
 -

 Key: JENKINS-13429
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429
 Project: Jenkins
  Issue Type: Bug
  Components: nested-view
Affects Versions: current
Reporter: M S
Assignee: Kohsuke Kawaguchi
  Labels: jenkins, plugin, views

 Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 
 1.1.2
 User has read permissions for View but Jenkins main page is missing Nested 
 views (even if they have sub views with jobs).
 Adding configure perms for View results in Nested views showing up 
 correctly.
 It looks like it's connected with:
 Added the View.READ permission to control visibility of views, and updated 
 the default implementation to hide empty views. (issue 3681)

--
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-13429) Nested views not showing up with just read perms for View

2012-05-14 Thread jos...@java.net (JIRA)


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

Jose Sa edited comment on JENKINS-13429 at 5/14/12 2:43 PM:


Upgraded from 1.456 (which had nested views of nested views showing ok) to 
1.462 and now it only shows the default All view and no nested views.
Had to revert and will have to stick with 1.458 until nested tabs can be 
visible again with anonymous view.read permission.

  was (Author: josesa):
Upgraded from 1.456 (which had nested views of nested views showing ok) to 
1.462 and now it only shows the default All view and no nested views.
Had to revert and will have to stick with 1.458 until nested tabs can be 
visible again with anonymous view.read permission is working.
  
 Nested views not showing up with just read perms for View
 -

 Key: JENKINS-13429
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429
 Project: Jenkins
  Issue Type: Bug
  Components: nested-view
Affects Versions: current
Reporter: M S
Assignee: Kohsuke Kawaguchi
  Labels: jenkins, plugin, views

 Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 
 1.1.2
 User has read permissions for View but Jenkins main page is missing Nested 
 views (even if they have sub views with jobs).
 Adding configure perms for View results in Nested views showing up 
 correctly.
 It looks like it's connected with:
 Added the View.READ permission to control visibility of views, and updated 
 the default implementation to hide empty views. (issue 3681)

--
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-13736) Tag/label should allow TAG permission


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

SCM/JIRA link daemon resolved JENKINS-13736.


Resolution: Fixed

 Tag/label should allow TAG permission
 -

 Key: JENKINS-13736
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13736
 Project: Jenkins
  Issue Type: Bug
  Components: perforce
Affects Versions: current
Reporter: Steve Schwaller
Assignee: Rob Petti
Priority: Minor

 To tag a build currently requires users to have the ADMINISTER permission. 
 This should be expanded to allow or replaced with the TAG permission.

--
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-13736) Tag/label should allow TAG permission


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

SCM/JIRA link daemon commented on JENKINS-13736:


Code changed in jenkins
User: Rob Petti
Path:
 src/main/java/hudson/plugins/perforce/PerforceTagAction.java
http://jenkins-ci.org/commit/perforce-plugin/8e57d86fb1457e69bdb6e58e35e45772352dad29
Log:
  [FIXED JENKINS-13736] fixing getIconFileName for tagging

the icon should display whenever the user has permission, since we can have 
multiple tags






 Tag/label should allow TAG permission
 -

 Key: JENKINS-13736
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13736
 Project: Jenkins
  Issue Type: Bug
  Components: perforce
Affects Versions: current
Reporter: Steve Schwaller
Assignee: Rob Petti
Priority: Minor

 To tag a build currently requires users to have the ADMINISTER permission. 
 This should be expanded to allow or replaced with the TAG permission.

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

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

2012-05-14 Thread hans-juergen.haf...@nsn.com (JIRA)


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

Hans-Juergen Hafner updated JENKINS-10912:
--

Attachment: mem_1.460.jpg
mem_1.457.jpg

Memory consumption Firefox 12.0 (Red Hat Enterprise Linux Server release 6.0)

 Memory leak (?) in dashboard
 

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


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

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

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

2012-05-14 Thread hans-juergen.haf...@nsn.com (JIRA)


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

Hans-Juergen Hafner commented on JENKINS-10912:
---

I seems the problemm disappeared.
I made a memory consumption log of Firefox 12 with top in batch mode.
The following diagram shows increase of memory with Jenkins 1.457:


 Memory leak (?) in dashboard
 

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


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

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

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

2012-05-14 Thread hans-juergen.haf...@nsn.com (JIRA)

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

Hans-Juergen Hafner edited comment on JENKINS-10912 at 5/14/12 3:45 PM:

It seems the problem disappeared.
I made a memory consumption log of Firefox 12 on Red Hat Enterprise Linux 6.0
with top in batch mode. I opened dashboard and let Jenkins alone.
The following diagram shows increase of memory with Jenkins 1.457:
!mem_1.457.jpg|width=30%!
and here constant memory with Jenkins 1.460:
!mem_1.460.jpg|width=30%!

was (Author: hjhafner):
I seems the problemm disappeared.
I made a memory consumption log of Firefox 12 with top in batch mode.
The following diagram shows increase of memory with Jenkins 1.457:

Memory leak (?) in dashboard

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

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

[JIRA] (JENKINS-13767) Documentation unclear on how to publish scan-build results

2012-05-14 Thread steven.peter...@gmail.com (JIRA)

Steven Peterson created JENKINS-13767:
-

 Summary: Documentation unclear on how to publish scan-build results
 Key: JENKINS-13767
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13767
 Project: Jenkins
  Issue Type: Improvement
  Components: clang-scanbuild
Reporter: Steven Peterson
Assignee: Josh Kennedy


The documentation currently says If you wish to have trend charts generated, 
check the checkbox for 'Publish Clang scan-build reports'.

In reality, it's necessary to to add a post-build action in order to do this. 
The referenced checkbox doesn't actually exist. I finally figured this out, but 
for a first-time user it makes things very difficult to understand.

--
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-10405) Post-receive hook doesn't work

2012-05-14 Thread ash...@hotmail.com (JIRA)


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

asher newcomer commented on JENKINS-10405:
--

I wasted a few hours on this before stumbling across Chris' comment above. I 
can confirm that this all works fine, even with HTTPS and Active Directory 
authentication in Jenkins. You just need to be sure *NOT* to use the specific 
Jenkins(GitHub plugin) webhook in Github, and rather choose the generic one.

 Post-receive hook doesn't work
 --

 Key: JENKINS-10405
 URL: https://issues.jenkins-ci.org/browse/JENKINS-10405
 Project: Jenkins
  Issue Type: Bug
  Components: github
Affects Versions: current
 Environment: 64-bit Ubuntu Maverick server, Sun Java 6 JVM, official 
 .debs.
Reporter: ieure
Assignee: Kevin Sawicki
 Attachments: security-settings.png


 I configured GitHub's web hooks for a project and pushed code, but the job 
 didn't build. I captured the payload with PostBin: 
 http://www.postbin.org/sq1n8a ; then sent it with Curl to see what was going 
 on:
 curl -k -H 'Content-Type: application/x-www-form-urlencoded' -XPOST 
 https://ci.public.simplegeo.com/github-webhook/ -d...@x.js
 I received this stacktrace in response: https://gist.github.com/1095538

--
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-12424) More correct and specific build state change reasons from Warnings

2012-05-14 Thread ullrich.haf...@gmail.com (JIRA)

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

Ulli Hafner commented on JENKINS-12424:
---

Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins
Analysis Plug-ins (Compile)
#502|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/502/]
[JENKINS-12424] Added links to new and priority warnings. (Revision
b72cda9a98a5d11b5b4be355bf87d9aa30f55e86)

Result = SUCCESS

More correct and specific build state change reasons from Warnings
---

Key: JENKINS-12424
URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
Project: Jenkins
Issue Type: Improvement
Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor

I got this in my jobs console.
[WARNINGS] Setting build status to FAILURE since total number of annotations
exceeds the threshold 200: [HIGH, NORMAL, LOW]
Two issues.
1. text says total, but this was actually a compute status since reference
build (new) gate.
2. text should say which specific criteria was exceeded
3. it doesn't tell you what the actual number/difference was
E.g.
[WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH
annotations exceeds the threshold of 200 by 34 or 17%.

[JIRA] (JENKINS-13768) default parameter values are ignored when triggering parameterized build from groovy post-build script

2012-05-14 Thread evilch...@java.net (JIRA)

evilchili created JENKINS-13768:
---

 Summary: default parameter values are ignored when triggering 
parameterized build from groovy post-build script
 Key: JENKINS-13768
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13768
 Project: Jenkins
  Issue Type: Bug
  Components: parameterized-trigger
Reporter: evilchili
Assignee: huybrechts


Steps to reproduce:

1. create job Foo with two string parameters: MAJOR, with default value '1', 
MINOR, with default value '0'
2. create job Bar with a groovy post-build hook thus:

{code}
  def params = []
  params.push( new StringParameterValue( 'MINOR', 2 ) )
  def foo = manager.hudson.getJob( 'Foo' )
  foo.scheduleBuild( 2, new Cause.UpstreamCause( manager.build ), new 
ParametersAction( params ) )
{code}

3. build Bar


Expected Result:

Foo builds with parameter values MAJOR=1, MINOR=2


Actual Result:

Foo build with parameter values MINOR=2


If MAJOR isn't specified in the parameter list when invoking the build, it 
should use the default value in Foo's configuration.  Instead, the parameter 
isn't evaluated at all.



--
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-12424) More correct and specific build state change reasons from Warnings

2012-05-14 Thread ullrich.haf...@gmail.com (JIRA)


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

Ulli Hafner resolved JENKINS-12424.
---

Resolution: Fixed

 More correct and specific build state change reasons from Warnings 
 ---

 Key: JENKINS-12424
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
 Project: Jenkins
  Issue Type: Improvement
  Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor

 I got this in my jobs console.
 [WARNINGS] Setting build status to FAILURE since total number of annotations 
 exceeds the threshold 200: [HIGH, NORMAL, LOW]
 Two issues.
 1. text says total, but this was actually a compute status since reference 
 build (new) gate.
 2. text should say which specific criteria was exceeded
 3. it doesn't tell you what the actual number/difference was
 E.g.
 [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH 
 annotations exceeds the threshold of 200 by 34 or 17%.

--
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-13277) Global environment variables are not being resolved in Email Notification Recipients list for maven 2/3 projects


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

Slide-O-Mix updated JENKINS-13277:
--

Component/s: (was: email-ext)

 Global environment variables are not being resolved in Email Notification 
 Recipients list for maven 2/3 projects
 

 Key: JENKINS-13277
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13277
 Project: Jenkins
  Issue Type: Bug
  Components: notification
Affects Versions: current
Reporter: jfreej

 When using a global environment variable, defined in Manage Jenkins  
 Configure System  Environment Variables (e.g. ALERT_EMAIL_LIST), in the 
 Email Notification  Recipients list of a maven 2/3 project (e.g. 
 ${ALERT_EMAIL_LIST}) the environment variable is not resolved. In the 
 console output we see: Sending e-mails to: ${ALERT_EMAIL_LIST}@test.com.
 Note that it DOES work in an free-style software project.
 So, it does not work within hudson.maven.reporters.MavenMailer, but it does 
 work within hudson.tasks.Mailer.

--
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-13715) User email suffixes are getting overwritten with the with the subversion repo UUID


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

Slide-O-Mix commented on JENKINS-13715:
---

Please try 2.20

 User email suffixes are getting overwritten with the with the subversion repo 
 UUID
 --

 Key: JENKINS-13715
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13715
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext, subversion
 Environment: Ubuntu 8.04
 Jenkins: 1.447.1
 Plugins: 
 javadoc   1.0 truefalse
 maven-plugin  1.447.1 truefalse
 ant   1.1 truefalse
 analysis-core 1.18truefalse
 pmd   3.14truefalse
 cvs   1.6 truefalse
 ci-game   1.18truefalse
 instant-messaging 1.21truefalse
 ircbot2.18truefalse
 subversion1.23truetrue
 ssh-slaves0.21truefalse
 claim 1.7 truefalse
 translation   1.8 truefalse
 bugzilla  1.4 false   false
 WebSVN2   0.9 truefalse
 email-ext 2.19truefalse
 parameterized-trigger 2.12truefalse
 git   1.1.12  truefalse
 repository0.7 truefalse
 bruceschneier 0.1 truefalse
 global-build-stats1.0 truefalse
 rebuild   1.9 truefalse
 greenballs1.10truefalse
 log-parser1.0.8   truefalse
 schedule-failed-builds1.1 false   false
 analysis-collector1.12truefalse
 radiatorviewplugin1.13truefalse
 xunit 1.5 truefalse
Reporter: David Pattison

 Several users on the system can't get any build emails.
 The email keep getting set to davidp@046000e8-c612-472f-bb51-fe359d1450d5 
 For certain users.
 * This only happens to users who have configs set, in 
 $JENKINS_HOME/users/user-name.xml
 * The number at the end is the Subversion UUID.
 * Removing/deleting/modifying the user configs does not work.
 This is very similar to the 
 https://issues.jenkins-ci.org/browse/JENKINS-11731, but only applies to some 
 users.

--
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-13607) certain projects can't send email: javax.mail.MessagingException: Could not connect to SMTP host: mail.recondotech.com, port: 25, response: 421


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

Slide-O-Mix commented on JENKINS-13607:
---

I'm unable to reproduce this, please give more information.

 certain projects can't send email: javax.mail.MessagingException: Could not 
 connect to SMTP host: mail.recondotech.com, port: 25, response: 421
 ---

 Key: JENKINS-13607
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13607
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
 /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
 -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
 /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
 --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
 --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
 --handlerCountMaxIdle=20
Reporter: Adam Sloan
  Labels: email, jenkins

 Loss of functionality: emails aren't getting sent out
 Build Console Output:
 Build step 'Execute shell' marked build as failure
 Emma: looking for coverage reports in the provided path: 
 target/site/emma/coverage.xml
 Sending e-mails to: aslo...@gmail.com
 ERROR: Could not connect to SMTP host: mail.recondotech.com, port: 25, 
 response: 421
 javax.mail.MessagingException: Could not connect to SMTP host: 
 mail.recondotech.com, port: 25, response: 421
   at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1922)
   at 
 com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638)
   at javax.mail.Service.connect(Service.java:295)
   at javax.mail.Service.connect(Service.java:176)
   at javax.mail.Service.connect(Service.java:125)
   at javax.mail.Transport.send0(Transport.java:194)
   at javax.mail.Transport.send(Transport.java:124)
   at hudson.tasks.MailSender.execute(MailSender.java:114)
   at 
 hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:1012)
   at hudson.model.Run.run(Run.java:1465)
   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Notifying upstream projects of job completion
 Finished: 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-13563) Attachment filepath does not support token reference


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

Slide-O-Mix commented on JENKINS-13563:
---

The attachment field does not currently support tokens, it uses the ANT file 
pattern syntax. Try logs/*.log



 Attachment filepath does not support token reference
 

 Key: JENKINS-13563
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13563
 Project: Jenkins
  Issue Type: Improvement
  Components: email-ext
Reporter: Sam He

 I defined an string parameter named env.
 email content can retrieve it with token ${ENV, var=env}.
 However, attachment field cannot solve the filepath with the tocken: 
 attachment:  logs/${ENV, var=env}.log
 Is there any suggestion on this behavior ?

--
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-13583) Error about sending to an empty list of recipients


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

Slide-O-Mix commented on JENKINS-13583:
---

Please put a screenshot up of your configuration and the build log.

 Error about sending to an empty list of recipients
 --

 Key: JENKINS-13583
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13583
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext, git
 Environment: Jenkins version 1.460, git plugin: 1.1.17, email-ext: 
 2.20
Reporter: jpschewe
Assignee: Nicolas De Loof

 Sometimes my jobs won't send emails and I will see the message An attempt to 
 send an e-mail to empty list of recipients, ignored. You can see an email of 
 this at http://mtu.net:8042/job/fll-release/20/. I have this job setup to 
 send only to the recipient list ($DEFAULT_RECIPIENTS) for all actions. I've 
 received this error on jobs setup to use the committers list as well.

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

[JIRA] (JENKINS-12614) Create a tutorial on how to configure in jenkins


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

Slide-O-Mix closed JENKINS-12614.
-

Resolution: Not A Defect

The wiki is the place for this, feel free to update with additional information.

 Create a tutorial on how to configure in jenkins
 

 Key: JENKINS-12614
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12614
 Project: Jenkins
  Issue Type: Improvement
  Components: email-ext
Affects Versions: current
Reporter: Ravi Teja Lokineni
  Labels: documentation

 Please create a tutorial by using screenshots(preferably) on the Wiki page. I 
 was not able to configure the email-ext plugin I had it installed on Jenkins 
 since 6 months and wasn't able to figure out why it's not working.
 Please ignore if it exits already and provide a link to that page. Thanks.

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

[JIRA] (JENKINS-13338) Add ability to have Still Failing only send an email once


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

Slide-O-Mix closed JENKINS-13338.
-

Resolution: Won't Fix

I don't think this will be implemented, the use case seems pretty specific. The 
still failing is supposed to be annoying. If you don't want it, you can turn 
off the trigger for that email.

 Add ability to have Still Failing only send an email once
 -

 Key: JENKINS-13338
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13338
 Project: Jenkins
  Issue Type: New Feature
  Components: email-ext
Reporter: Michael Haderman
Priority: Minor

 The scenario that this would resolve is:
 1) Run jenkins job once (in my case a selenium test)
 2) If it fails don't send an email. Use Naginator to re-run the job
 3) If it fails again send an email using email-ext
 4) If it fails again, don't send any more emails 
 5) Send an email once it is stable.

--
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-13672) Allow email attachments at TRIGGER LEVEL


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

Slide-O-Mix reassigned JENKINS-13672:
-

Assignee: Slide-O-Mix

 Allow email attachments at TRIGGER LEVEL
 

 Key: JENKINS-13672
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13672
 Project: Jenkins
  Issue Type: New Feature
  Components: email-ext
Reporter: Paul Mendelson
Assignee: Slide-O-Mix
Priority: Minor

 Currently for a specific trigger (before build, success, etc) you can 
 configure
 Recipient List, Subject, and Content.  It would be useful to also configure 
 attachments.

--
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-13672) Allow email attachments at TRIGGER LEVEL


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

Work on JENKINS-13672 started by Slide-O-Mix.

 Allow email attachments at TRIGGER LEVEL
 

 Key: JENKINS-13672
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13672
 Project: Jenkins
  Issue Type: New Feature
  Components: email-ext
Reporter: Paul Mendelson
Assignee: Slide-O-Mix
Priority: Minor

 Currently for a specific trigger (before build, success, etc) you can 
 configure
 Recipient List, Subject, and Content.  It would be useful to also configure 
 attachments.

--
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-13700) Build hangs during while Sending email


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

Slide-O-Mix commented on JENKINS-13700:
---

Do you have email suffix resolution turned on?

 Build hangs during while Sending email
 

 Key: JENKINS-13700
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13700
 Project: Jenkins
  Issue Type: Bug
  Components: core, email-ext
 Environment: OS: 
Master: Ubuntu 10.04
Slaves: OSX 1.7.3, Win2K8 Server, Win XP, Win2K3 Server
 Jenkins: 1.424.1
 Plugins:
Email-ext plugin: 2.14.1
Configuration Slicing plugin: 1.28.1
Jenkins GIT plugin: 1.1.18
Perforce Plugin: 1.3.9
Reporter: crwong

 When building on the OSX slave, the build will get to the point where the 
 console says that it is sending email, and it stays there.  If you look at 
 the list of executors, the progress bar shows that the build is still on 
 progress.  If you look at the job's status page, it looks like the job has 
 completed, and it is no longer running.  Clicking on the Stop build button 
 next to the job in the Build Executors Status section, does nothing.  The 
 only way to clear the executor is to restart 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-12424) More correct and specific build state change reasons from Warnings

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

SCM/JIRA link daemon commented on JENKINS-12424:

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/analysis/core/BuildResultEvaluator.java
src/main/resources/hudson/plugins/analysis/Messages.properties
src/main/resources/hudson/plugins/analysis/Messages_de.properties
http://jenkins-ci.org/commit/analysis-core-plugin/5c21e8054698196040a75cf4f18944b8bef94d51
Log:
[Fixed JENKINS-12424] Added messages for one warning.

More correct and specific build state change reasons from Warnings
---

[JIRA] (JENKINS-8962) Cannot change parameter value for promotion re-execution

2012-05-14 Thread liamjbenn...@java.net (JIRA)


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

liamjbennett commented on JENKINS-8962:
---

This should be a configurable option. Also you may want to disable the ability 
to edit parameters if the previous promotion has failed, thus forcing the user 
to fix the failure before moving on to the next promotion.

 Cannot change parameter value for promotion re-execution
 

 Key: JENKINS-8962
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8962
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Reporter: kirill_evstigneev

 For parametrized promotion:
 It is possible to set parameters values only for the first promotion 
 execution for a specific build.
 For re-execution parameters cannot be changed. Promotion process gets the 
 same values.

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

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


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

Amir Isfy commented on JENKINS-13227:
-

This is embarrassing...but where do these artifacts go in my /var/lib/jenkins?

 CVS plugin 2.1 does not detect changes
 --

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


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

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

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

2012-05-14 Thread michael.m.cla...@gmail.com (JIRA)


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

Michael Clarke commented on JENKINS-13227:
--

You only need to download the hpi file and put it in the plugins folder in 
Jenkins home. If one does not already exist, you'll need to create an empty 
file called cvs.hpi.pinned then restart your Jenkins instance. If Jenkins is 
already running then you can goto the 'Advanced' tab in update centre and use 
the 'Upload Plugin' section to install the hpi file directly and therefore 
don't need to worry about incorrectly over-writing incorrect files.

 CVS plugin 2.1 does not detect changes
 --

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


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

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

[JIRA] (JENKINS-13753) plink call in build.bat file doesn't execute remote shell script

2012-05-14 Thread charlie.sal...@nielsen.com (JIRA)


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

Charlie Salemi commented on JENKINS-13753:
--

I sent an email with the .bat file attached.

 plink call in build.bat file doesn't execute remote shell script
 

 Key: JENKINS-13753
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13753
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Win 7 64bit
Reporter: Charlie Salemi
  Labels: jenkins

 Have a build.bat file on Win 7 64bit system.  build.bat contains plink call 
 to execute shell script on remote Linux server passing four arguments.  When 
 the build.bat is executed from the Command Prompt the plink command executes 
 properly.  When the same build.bat file is executed via Jenkins the plink 
 command does not execute the shell script on the remote server.
 The build.bat file does succesfully execute another plink call to a different 
 Linux server but only passing two arguments.  Not sure what is causing this 
 inconsistency.

--
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-13753) plink call in build.bat file doesn't execute remote shell script

2012-05-14 Thread charlie.sal...@nielsen.com (JIRA)


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

Charlie Salemi updated JENKINS-13753:
-

Attachment: buildAll.bat

This is a scrubbed version but you should get the picture of what I am trying 
to do.

 plink call in build.bat file doesn't execute remote shell script
 

 Key: JENKINS-13753
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13753
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
 Environment: Win 7 64bit
Reporter: Charlie Salemi
  Labels: jenkins
 Attachments: buildAll.bat


 Have a build.bat file on Win 7 64bit system.  build.bat contains plink call 
 to execute shell script on remote Linux server passing four arguments.  When 
 the build.bat is executed from the Command Prompt the plink command executes 
 properly.  When the same build.bat file is executed via Jenkins the plink 
 command does not execute the shell script on the remote server.
 The build.bat file does succesfully execute another plink call to a different 
 Linux server but only passing two arguments.  Not sure what is causing this 
 inconsistency.

--
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-13583) Error about sending to an empty list of recipients

2012-05-14 Thread jpsch...@mtu.net (JIRA)


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

jpschewe updated JENKINS-13583:
---

Attachment: fll-build.log

 Error about sending to an empty list of recipients
 --

 Key: JENKINS-13583
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13583
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext, git
 Environment: Jenkins version 1.460, git plugin: 1.1.17, email-ext: 
 2.20
Reporter: jpschewe
Assignee: Nicolas De Loof
 Attachments: fll-build.log


 Sometimes my jobs won't send emails and I will see the message An attempt to 
 send an e-mail to empty list of recipients, ignored. You can see an email of 
 this at http://mtu.net:8042/job/fll-release/20/. I have this job setup to 
 send only to the recipient list ($DEFAULT_RECIPIENTS) for all actions. I've 
 received this error on jobs setup to use the committers list as well.

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

[JIRA] (JENKINS-13583) Error about sending to an empty list of recipients

2012-05-14 Thread jpsch...@mtu.net (JIRA)


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

jpschewe updated JENKINS-13583:
---

Attachment: fll-email-ext-config.jpg
fll-git-config-1.jpg
fll-git-config-0.jpg

Screenshots of my config. It doesn't all fit on one page, so I included the git 
config as 2 screen shots and the email-ext config as a third screen shot.

 Error about sending to an empty list of recipients
 --

 Key: JENKINS-13583
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13583
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext, git
 Environment: Jenkins version 1.460, git plugin: 1.1.17, email-ext: 
 2.20
Reporter: jpschewe
Assignee: Nicolas De Loof
 Attachments: fll-build.log, fll-email-ext-config.jpg, 
 fll-git-config-0.jpg, fll-git-config-1.jpg


 Sometimes my jobs won't send emails and I will see the message An attempt to 
 send an e-mail to empty list of recipients, ignored. You can see an email of 
 this at http://mtu.net:8042/job/fll-release/20/. I have this job setup to 
 send only to the recipient list ($DEFAULT_RECIPIENTS) for all actions. I've 
 received this error on jobs setup to use the committers list as well.

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

[JIRA] (JENKINS-13769) Add URLs for RDoc and Textile markup

2012-05-14 Thread dieterdeme...@gmail.com (JIRA)


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

Work on JENKINS-13769 started by Dieter De Meyer.

 Add URLs for RDoc and Textile markup
 

 Key: JENKINS-13769
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13769
 Project: Jenkins
  Issue Type: Improvement
  Components: plugin
Affects Versions: current
Reporter: Dieter De Meyer
Assignee: Dieter De Meyer
Priority: Trivial
  Labels: plugin, plugins
 Fix For: current


 A minor enhancement to add the URLs for RDoc and Textile markup to the 
 Embeddable Build Status 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-13770) StarTeam Plugin SCM Polling failing on Slave machines

2012-05-14 Thread john.c...@staples.com (JIRA)

John Cook created JENKINS-13770:
---

 Summary: StarTeam Plugin SCM Polling failing on Slave machines
 Key: JENKINS-13770
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13770
 Project: Jenkins
  Issue Type: Bug
  Components: starteam
Affects Versions: current
 Environment: Jenkins Version 1.417 installed on AIX. Slave:  
Jenkins running as a service on Windows 2003. StarTeam Plugin Version: 
0.6.7  
Reporter: John Cook
Assignee: jan_ruzicka


StarTeam Polling does not appear to work when configured to run on a Slave 
(tested Windows 2003).  Receiving the below error when the poll occurs.   
The error can be viewed in the StarTeam Polling Log.  


SCM Poll Config:   */15 * * * *



Started on May 14, 2012 1:00:39 PM
FATAL: remote file operation failed: D:\Jenkins\workspace\NARASR at 
hudson.remoting.Channel@13381338:10.128.26.15
hudson.util.IOException2: remote file operation failed: 
D:\Jenkins\workspace\NARASR at hudson.remoting.Channel@13381338:10.128.26.15
at hudson.FilePath.act(FilePath.java:754)
at hudson.FilePath.act(FilePath.java:740)
at hudson.plugins.starteam.StarTeamSCM.pollChanges(StarTeamSCM.java:181)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject.poll(AbstractProject.java:1300)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
at 
hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:453)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:315)
at java.util.concurrent.FutureTask.run(FutureTask.java:150)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:898)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:920)
at java.lang.Thread.run(Thread.java:736)
Caused by: java.io.IOException: Unable to serialize 
hudson.FilePath$FileCallableWrapper@17a817a8
at hudson.remoting.UserRequest.serialize(UserRequest.java:166)
at hudson.remoting.UserRequest.init(UserRequest.java:62)
at hudson.remoting.Channel.call(Channel.java:666)
at hudson.FilePath.act(FilePath.java:747)
... 13 more
Caused by: java.io.NotSerializableException: hudson.model.FreeStyleBuild
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1165)
at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1401)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1159)
at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1401)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1159)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:332)
at hudson.remoting.UserRequest._serialize(UserRequest.java:155)
at hudson.remoting.UserRequest.serialize(UserRequest.java:164)
at hudson.remoting.UserRequest.init(UserRequest.java:59)
... 15 more
Done. Took 48 ms
No changes

--
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-13737) Javascript error when selecting Editable Email Notification


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

Slide-O-Mix reassigned JENKINS-13737:
-

Assignee: Slide-O-Mix

 Javascript error when selecting Editable Email Notification
 -

 Key: JENKINS-13737
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
 Plugin 2.20
Reporter: Noel Bernardez
Assignee: Slide-O-Mix
  Labels: email-ext, jenkins

 In Jenkins ver. 1.463, when selecting Editable Email Notification in the 
 Add post-build action, getting the following Javascript error 
 Message: 'emailExtInit' is undefined
 Line: 480
 Char: 17
 Code: 0
 URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-12424) More correct and specific build state change reasons from Warnings


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

dogfood commented on JENKINS-12424:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_analysis-core 
#10451|http://ci.jenkins-ci.org/job/plugins_analysis-core/10451/]
 [JENKINS-12424] Added links to new and priority warnings. (Revision 
b72cda9a98a5d11b5b4be355bf87d9aa30f55e86)
[Fixed JENKINS-12424] Added messages for one warning. (Revision 
5c21e8054698196040a75cf4f18944b8bef94d51)

 Result = SUCCESS
Ulli Hafner : 
Files : 
* src/main/java/hudson/plugins/analysis/core/ReporterDescriptor.java
* src/main/java/hudson/plugins/analysis/core/HealthAwarePublisher.java
* src/test/java/hudson/plugins/analysis/core/BuildResultEvaluatorTest.java
* src/main/java/hudson/plugins/analysis/core/MavenResultAction.java
* src/main/java/hudson/plugins/analysis/core/BuildResult.java
* src/main/resources/hudson/plugins/analysis/Messages_de.properties
* src/main/java/hudson/plugins/analysis/core/BuildResultEvaluator.java
* src/main/java/hudson/plugins/analysis/core/HealthAwareReporter.java
* src/main/resources/hudson/plugins/analysis/Messages.properties
* src/main/java/hudson/plugins/analysis/core/AbstractResultAction.java

Ulli Hafner : 
Files : 
* src/main/resources/hudson/plugins/analysis/Messages_de.properties
* src/main/java/hudson/plugins/analysis/core/BuildResultEvaluator.java
* src/main/resources/hudson/plugins/analysis/Messages.properties


 More correct and specific build state change reasons from Warnings 
 ---

 Key: JENKINS-12424
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
 Project: Jenkins
  Issue Type: Improvement
  Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor

 I got this in my jobs console.
 [WARNINGS] Setting build status to FAILURE since total number of annotations 
 exceeds the threshold 200: [HIGH, NORMAL, LOW]
 Two issues.
 1. text says total, but this was actually a compute status since reference 
 build (new) gate.
 2. text should say which specific criteria was exceeded
 3. it doesn't tell you what the actual number/difference was
 E.g.
 [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH 
 annotations exceeds the threshold of 200 by 34 or 17%.

--
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-13452) Include an option to include TAP Stream in the console output or somewhere in Jenkins UI


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

dogfood commented on JENKINS-13452:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_tap 
#6|http://ci.jenkins-ci.org/job/plugins_tap/6/]
 [FIXED JENKINS-13452] Added option to output TAP stream after parsing it 
(Revision 6b914cd93776e9a96b9ec23b2e45f4ed6044ff1a)

 Result = SUCCESS
Bruno P. Kinoshita : 
Files : 
* src/main/java/org/tap4j/plugin/TapRemoteCallable.java
* src/main/java/org/tap4j/plugin/TapPublisher.java
* src/main/resources/org/tap4j/plugin/TapPublisher/config.jelly


 Include an option to include TAP Stream in the console output or somewhere in 
 Jenkins UI
 

 Key: JENKINS-13452
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13452
 Project: Jenkins
  Issue Type: Improvement
  Components: tap
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita

 Include an option to include TAP Stream in the console output or somewhere in 
 Jenkins UI

--
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-13453) Report passed TODO tests

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

dogfood commented on JENKINS-13453:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_tap
#6|http://ci.jenkins-ci.org/job/plugins_tap/6/]
[FIXED JENKINS-13453] Removed the code that changed the test result with
TODO directive to Failed (not ok) (Revision
8480aa6a7b9043b301079d8f76eb957ab7174e09)

Result = SUCCESS
Bruno P. Kinoshita :
Files :
* src/main/resources/org/tap4j/plugin/tags/status.jelly
* src/main/resources/org/tap4j/plugin/tags/directive.jelly
* src/main/java/org/tap4j/plugin/TapPublisher.java

Report passed TODO tests

Key: JENKINS-13453
URL: https://issues.jenkins-ci.org/browse/JENKINS-13453
Project: Jenkins
Issue Type: Improvement
Components: tap
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
Labels: improvement, tap, testing

It would be good if the plug-in had options to control the behavior with
TODO's. It also may need some rework parsing TAP to remove # or other
characters to help the user.
Moreover, it may not be necessarily a failure, having a TODO test.

[JIRA] (JENKINS-13736) Tag/label should allow TAG permission

2012-05-14 Thread jbeeck...@compliancesystems.com (JIRA)


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

dogfood commented on JENKINS-13736:
---

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! 
[plugins_perforce #227|http://ci.jenkins-ci.org/job/plugins_perforce/227/]
 [FIXED JENKINS-13736] fixing getIconFileName for tagging (Revision 
8e57d86fb1457e69bdb6e58e35e45772352dad29)

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


 Tag/label should allow TAG permission
 -

 Key: JENKINS-13736
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13736
 Project: Jenkins
  Issue Type: Bug
  Components: perforce
Affects Versions: current
Reporter: Steve Schwaller
Assignee: Rob Petti
Priority: Minor

 To tag a build currently requires users to have the ADMINISTER permission. 
 This should be expanded to allow or replaced with the TAG permission.

--
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-7024) Gerrit comment: Build Started nulljob/foo/1/

2012-05-14 Thread zlo...@java.net (JIRA)


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

zlosch commented on JENKINS-7024:
-

It took me an hour to hunt this down (and finally find this issue)...

Workaround is:

# Go to global configuration and save it
# Go to gerrit-trigger global configuration and save it
# Restart the daemon in the 'Control' section (not sure if this is really 
necessary)

 Gerrit comment: Build Started nulljob/foo/1/
 --

 Key: JENKINS-7024
 URL: https://issues.jenkins-ci.org/browse/JENKINS-7024
 Project: Jenkins
  Issue Type: Bug
  Components: gerrit-trigger
Reporter: rin_ne
Assignee: rsandell
Priority: Minor

 This issue is reproduced only on Hudson which system configuration is never 
 saved.
 If system configuration is never saved, Hudson URL is null.
 Regardless of whether Hudson URL is null or not, BUILDURL refers to it.
 Before saving gerrit global configuration, saving system configuration is 
 needed.

--
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-12423) Password masked by Mask Passwords are visible when using envinject plugin

2012-05-14 Thread gregory.boissi...@gmail.com (JIRA)


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

Gregory Boissinot commented on JENKINS-12423:
-

It is already released.
Please upgrade to 1.52
http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/envinject/1.52/

 Password masked by Mask Passwords are visible when using envinject plugin
 -

 Key: JENKINS-12423
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12423
 Project: Jenkins
  Issue Type: Bug
  Components: envinject, mask-passwords, perforce
 Environment: envinject1.9
 mask-passwords2.7.2
 Jenkins ver. 1.424.1
 Windows
 Perforce plugin 1.3.7
Reporter: Roger Myung
Assignee: Gregory Boissinot

 If I use the mask-passwords plugin to create a masked password, and also use 
 the envinject plugin to setup an environment, the masked password is visible 
 from the Injected Environment Variables link for each build.

--
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-13771) Jenkins not being triggered on a change to an external with new 1.4 SVN plugin.

Jay Beeckman created JENKINS-13771:
--

 Summary: Jenkins not being triggered on a change to an external 
with new 1.4 SVN plugin.
 Key: JENKINS-13771
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13771
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
Affects Versions: current
 Environment: Windows Server 2008, 32 bit.
Reporter: Jay Beeckman
Priority: Blocker


Previously, external commits would trigger a build.  This is no longer working 
after the 1.4 update to the Subversion 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-13737) Javascript error when selecting Editable Email Notification


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

Slide-O-Mix commented on JENKINS-13737:
---

Actually, with a fresh install of Jenkins 1.463 and Email-ext 2.20, I do not 
see any JS errors and I am able to add it as a post-build action. Please give 
more information for debug.

 Javascript error when selecting Editable Email Notification
 -

 Key: JENKINS-13737
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
 Plugin 2.20
Reporter: Noel Bernardez
Assignee: Slide-O-Mix
  Labels: email-ext, jenkins

 In Jenkins ver. 1.463, when selecting Editable Email Notification in the 
 Add post-build action, getting the following Javascript error 
 Message: 'emailExtInit' is undefined
 Line: 480
 Char: 17
 Code: 0
 URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-13737) Javascript error when selecting Editable Email Notification


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

Slide-O-Mix commented on JENKINS-13737:
---

Sorry, I take that back, I hit the wrong button. The issue looks like that the 
first eval'd script somehow loses its state. The first script initializes the 
emailExtInit variable and subsequent scripts use it.

 Javascript error when selecting Editable Email Notification
 -

 Key: JENKINS-13737
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
 Plugin 2.20
Reporter: Noel Bernardez
Assignee: Slide-O-Mix
  Labels: email-ext, jenkins

 In Jenkins ver. 1.463, when selecting Editable Email Notification in the 
 Add post-build action, getting the following Javascript error 
 Message: 'emailExtInit' is undefined
 Line: 480
 Char: 17
 Code: 0
 URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-13007) Git plugin cannot find revision to build on Windows

2012-05-14 Thread ido....@gmail.com (JIRA)


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

Ido Ran commented on JENKINS-13007:
---

I also have the same problem. After I upgrade from 1.1.15 to 1.1.18 I get this 
exact error

 Git plugin cannot find revision to build on Windows
 ---

 Key: JENKINS-13007
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13007
 Project: Jenkins
  Issue Type: Bug
  Components: git
 Environment: Windows 2008 Server 64 Bit
 NTFS
Reporter: ritzmann
Assignee: Nicolas De Loof
Priority: Critical

 After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on 
 Windows build slaves started failing like this:
 Started by user anonymous
 Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app
 Checkout:my-app / d:\hudson\workspace\my-app - 
 hudson.remoting.Channel@95ff886:win-slave1
 Using strategy: Default
 Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 
 (origin/master)
 Checkout:my-app / d:\hudson\workspace\my-app - 
 hudson.remoting.LocalChannel@470a4b80
 Fetching changes from 1 remote Git repository
 Fetching upstream changes from d:\hudson\shared\repo.git
 ERROR: Couldn't find any revision to build. Verify the repository and branch 
 configuration for this job.
 The builds on our Linux slaves are not affected. Wiping the workspaces on the 
 Windows slaves did not help. Both clones and checkouts/updates seem to fail 
 with the same error. Downgrading back to 1.1.14 made the Windows builds work 
 again.

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

[JIRA] (JENKINS-13700) Build hangs during while Sending email

2012-05-14 Thread crw...@java.net (JIRA)

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

crwong commented on JENKINS-13700:
--

I have a value entered for the Default user e-mail suffix. The only jobs
that seem to stall are the jobs using Git.

Build hangs during while Sending email

Key: JENKINS-13700
URL: https://issues.jenkins-ci.org/browse/JENKINS-13700
Project: Jenkins
Issue Type: Bug
Components: core, email-ext
Environment: OS:
Master: Ubuntu 10.04
Slaves: OSX 1.7.3, Win2K8 Server, Win XP, Win2K3 Server
Jenkins: 1.424.1
Plugins:
Email-ext plugin: 2.14.1
Configuration Slicing plugin: 1.28.1
Jenkins GIT plugin: 1.1.18
Perforce Plugin: 1.3.9
Reporter: crwong

When building on the OSX slave, the build will get to the point where the
console says that it is sending email, and it stays there. If you look at
the list of executors, the progress bar shows that the build is still on
progress. If you look at the job's status page, it looks like the job has
completed, and it is no longer running. Clicking on the Stop build button
next to the job in the Build Executors Status section, does nothing. The
only way to clear the executor is to restart Jenkins.

[JIRA] (JENKINS-13772) Produce tokens with Token Macro plugin

2012-05-14 Thread p...@nkey.com.br (JIRA)

Paul Eipper created JENKINS-13772:
-

 Summary: Produce tokens with Token Macro plugin
 Key: JENKINS-13772
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13772
 Project: Jenkins
  Issue Type: New Feature
  Components: xcode
Affects Versions: current
Reporter: Paul Eipper


Export tokens read from the configured project to be built.

I am specially interested in these values:
XCODE_BUNDLE_SHORT_VERSION = CFBundleShortVersionString
XCODE_BUNDLE_VERSION = CFBundleVersion

Also, after the build is completed:
XCODE_BUILD_OUTPUT_DIR = Build output 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-13773) Perform Jira release based on user action or certain plugin usage - Maven

2012-05-14 Thread u...@java.net (JIRA)

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

uded updated JENKINS-13773:
---

Description:
It would be better for those of us that use Maven to drive the Jira version
release process differently. Currently, if I am doing a build based on Maven in
the project that uses most of the Jira plugin features (Generate Release Notes,
Mark a JIRA version as Released, Move issues...) it will execute those steps
for every build. That's not the case if you are using Maven Release plugin -
then the normal builds should not touch the JIRA release/changelog/etc. parts
unless one is actually doing the release!

I see three different solutions for this case:

1. Add a link in the project (better yet - in a build!) toolbar to perform a
release of JIRA version for the project manually. The screen can ask user about
the version to release.
2. Add a tight integration to [M2 Release
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin] and other
release plugins - but that seems to be somewhat hard to do.
3. Provide an extension point to trigger the release process and let other
plugins authors (like [M2 Release
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin]) use it.

Of course all three solutions (better 1+2) can be implemented for greater
usability.

I would be happy to help out with this, BTW.

was:
It would be better for those of us that use Maven to drive the Jira version
release process differently. Currently, if I am doing a build based on Maven in
the project that uses most of the Jira plugin features (Generate Release Notes,
Mark a JIRA version as Released, Move issues...) it will execute those steps
for every build. That's not the case if you are using Maven Release plugin -
then the normal builds should not touch the JIRA release/changelog/etc. parts
unless one is actually doing the release!

I see three different solutions for this case:

Of course all three solutions (better 1+2) can be implemented for greater
usability.

Perform Jira release based on user action or certain plugin usage - Maven
-

Key: JENKINS-13773
URL: https://issues.jenkins-ci.org/browse/JENKINS-13773
Project: Jenkins
Issue Type: Improvement
Components: jira
Reporter: uded
Labels: plugin

It would be better for those of us that use Maven to drive the Jira version
release process differently. Currently, if I am doing a build based on Maven
in the project that uses most of the Jira plugin features (Generate Release
Notes, Mark a JIRA version as Released, Move issues...) it will execute those
steps for every build. That's not the case if you are using Maven Release
plugin - then the normal builds should not touch the JIRA
release/changelog/etc. parts unless one is actually doing the release!
I see three different solutions for this case:
1. Add a link in the project (better yet - in a build!) toolbar to perform a
release of JIRA version for the project manually. The screen can ask user
about the version to release.
2. Add a tight integration to [M2 Release
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin] and
other release plugins - but that seems to be somewhat hard to do.
3. Provide an extension point to trigger the release process and let other
plugins authors (like [M2 Release
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin]) use it.
Of course all three solutions (better 1+2) can be implemented for greater
usability.
I would be happy to help out with this, BTW.

[JIRA] (JENKINS-13773) Perform Jira release based on user action or certain plugin usage - Maven

2012-05-14 Thread u...@java.net (JIRA)

uded created JENKINS-13773:
--

 Summary: Perform Jira release based on user action or certain 
plugin usage - Maven
 Key: JENKINS-13773
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13773
 Project: Jenkins
  Issue Type: Improvement
  Components: jira
Reporter: uded


It would be better for those of us that use Maven to drive the Jira version 
release process differently. Currently, if I am doing a build based on Maven in 
the project that uses most of the Jira plugin features (Generate Release Notes, 
Mark a JIRA version as Released, Move issues...) it will execute those steps 
for every build. That's not the case if you are using Maven Release plugin - 
then the normal builds should not touch the JIRA release/changelog/etc. parts 
unless one is actually doing the release!

I see three different solutions for this case:

1. Add a link in the project (better yet - in a build!) toolbar to perform a 
release of JIRA version for the project manually. The screen can ask user about 
the version to release.
2. Add a tight integration to [M2 Release 
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin] and other 
release plugins - but that seems to be somewhat hard to do.
3. Provide an extension point to trigger the release process and let other 
plugins authors (like [M2 Release 
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin]) use it.

Of course all three solutions (better 1+2) can be implemented for greater 
usability.

--
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-13435) Auto Install jdk from oracle downloads html instead of bin

2012-05-14 Thread andreas.hochste...@gmail.com (JIRA)


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

Andreas Hochsteger commented on JENKINS-13435:
--

Hi,

I've just upgraded to 1.464 but I still get the same problem.
Here's my log output:
{code}
[EnvInject] - Loading node environment variables.
Installing /var/lib/jenkins/tools/JDK6/jdk.sh
[JDK6] $ /var/lib/jenkins/tools/JDK6/jdk.sh -noregister
/var/lib/jenkins/tools/JDK6/jdk.sh: 1: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open html: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 2: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open head: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 3: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open title: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 3: /var/lib/jenkins/tools/JDK6/jdk.sh: 
Request: not found
/var/lib/jenkins/tools/JDK6/jdk.sh: 4: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open META: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 5: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open link: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 6: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open link: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 7: /var/lib/jenkins/tools/JDK6/jdk.sh: 
: not found
/var/lib/jenkins/tools/JDK6/jdk.sh: 8: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open body: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 9: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open div: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 10: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open table: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 11: /var/lib/jenkins/tools/JDK6/jdk.sh: 
cannot open tr: No such file
/var/lib/jenkins/tools/JDK6/jdk.sh: 12: /var/lib/jenkins/tools/JDK6/jdk.sh: 
Syntax error: redirection unexpected
[EnvInject] - [ERROR] - SEVERE ERROR occurs: hudson.AbortException: JDK konnte 
nicht installiert werden.
Capturing build context.
Finished: FAILURE
{code}

Is there something (e.g. a work-around) I can do about it?

Thanks,

Andreas


 Auto Install jdk from oracle downloads html instead of bin
 --

 Key: JENKINS-13435
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13435
 Project: Jenkins
  Issue Type: Bug
  Components: core
Reporter: Jenni Syed

 On version 1.455 (saw on 1.459 as well), choosing to auto-install the jdk 
 from oracle results in an html page being downloaded and the message below. 
 When I look at the jdk.sh, it's the html page from oracle complaining about 
 not accepting the license terms. Also see: 
 https://groups.google.com/group/jenkinsci-users/browse_thread/thread/1d510fae9816f086
 {quote}
 Installing JDK jdk-1.5.0_22-oth-JPR
 Downloading JDK from 
 http://download.oracle.com/otn/java/jdk/1.5.0_22/jdk-1_5_0_22-linux-amd64.bin
 Downloading 5307bytes
 Installing /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh
 [jdk1.5_22] $ /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh -noregister
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 1: html: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 2: head: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 3: title: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 4: META: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 5: link: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 6: link: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 7: 
 : command not found
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 8: body: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 9: div: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 10: table: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 11: tr: No such file or 
 directory
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 12: syntax error near 
 unexpected token `'
 /home/exodus/jenkins/tools/jdk1.5_22/jdk.sh: line 12: `  td rowspan=2 
 valign=middle nowrapa href=http://www.oracle.com;img 
 src=/errors/us/assets/oralogo-small.gif width=154 height=19 hspace=10 
 vspace=25 border=0 /a/td
 '
 [EnvInject] - [ERROR] - SEVERE ERROR occurs: hudson.AbortException: Failed to 
 install JDK. Exit code=2
 Finished: FAILURE
 {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-13227) CVS plugin 2.1 does not detect changes


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

Amir Isfy commented on JENKINS-13227:
-

Here is what happens when I tried it on multiple slaves (Win and Linux):

- I commit a dummy change to the branch.
- Let the project kick off with an SCM poll, as well as I manually triggering 
it on another slave.
- Cleaned out the workspaces, so this is a clean checkout.
- The checkout by the Master goes fine. 
- There is no 'computing changelog' stage.
- The matrix builds are initiated an in both instances I get: 

16:00:58  hudson.util.IOException2: remote file operation failed: 
workspace_location at hudson.remoting.Channel@28509953:slave_name
16:00:58at hudson.FilePath.act(FilePath.java:828)
16:00:58at hudson.FilePath.act(FilePath.java:814)
16:00:58at hudson.scm.CVSSCM.perform(CVSSCM.java:877)
16:00:58at hudson.scm.CVSSCM.checkout(CVSSCM.java:808)
16:00:58at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
16:00:58at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
16:00:58at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
16:00:58at hudson.model.Run.run(Run.java:1434)
16:00:58at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
16:00:58at 
hudson.model.ResourceController.execute(ResourceController.java:88)
16:00:58at hudson.model.Executor.run(Executor.java:239)
16:00:58  Caused by: java.io.IOException: Unable to serialize 
hudson.FilePath$FileCallableWrapper@30f3caf4
16:00:58at hudson.remoting.UserRequest.serialize(UserRequest.java:166)
16:00:58at hudson.remoting.UserRequest.init(UserRequest.java:62)
16:00:58at hudson.remoting.Channel.call(Channel.java:645)
16:00:58at hudson.FilePath.act(FilePath.java:821)
16:00:58... 10 more
16:00:58  Caused by: java.io.NotSerializableException: 
hudson.scm.CvsRepositoryItem
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
16:00:58at 
java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
16:00:58at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58at 
java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
16:00:58at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58at 
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
16:00:58at hudson.remoting.UserRequest._serialize(UserRequest.java:155)
16:00:58at hudson.remoting.UserRequest.serialize(UserRequest.java:164)
16:00:58... 13 more

After the failure, the build number says: No changes.

 CVS plugin 2.1 does not detect changes
 --

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


 As presented in the user group: 
 https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4
 We've been running Jenkins 1.451 and 1.454 on Windows XP

[JIRA] (JENKINS-6472) Jira plugin to view issue status in Hudson

2012-05-14 Thread u...@java.net (JIRA)


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

uded commented on JENKINS-6472:
---

[~pushy] - can You provide a visual representation of what you have in mind? I 
think I have time and I am willing to implement this.

 Jira plugin to view issue status in Hudson
 --

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

 It would be great if Jira plugin could view also status of each issue 
 (in-progress/resolved/closed) in Hudson. Currently it includes only link to 
 the issue and it is quite frustrating to open each issue separately and check 
 the status.

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

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


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

Amir Isfy commented on JENKINS-13227:
-

I have to correct. None of the above builds were triggered by an SCM change, 
they were all triggered manually.

Committed another dummy change. Wait for polling: No changes.

:(

 CVS plugin 2.1 does not detect changes
 --

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


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

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

[JIRA] (JENKINS-13774) Provide option for cloning all branches with Mercurial SCM

2012-05-14 Thread dave.h...@gmail.com (JIRA)

Dave Hunt created JENKINS-13774:
---

 Summary: Provide option for cloning all branches with Mercurial SCM
 Key: JENKINS-13774
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13774
 Project: Jenkins
  Issue Type: New Feature
  Components: mercurial
Affects Versions: current
Reporter: Dave Hunt
Assignee: Kohsuke Kawaguchi
Priority: Minor


We're using the Mercurial SCM plugin to clone a repository so that it can be 
archived and made available to other jobs via the Copy Artifact plugin. We 
can't use the plugin directly from these subsequent jobs because they actually 
use two separate repositories, so we have two jobs that provide such artifacts.

The problem is that we need to clone all branches, and when leaving the branch 
empty the 'default' branch is cloned/pulled. It would be great if there was an 
option grab all branches. At the moment we are using a workaround of the 'hg 
pull' command as one of our build steps.

--
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-13737) Javascript error when selecting Editable Email Notification

2012-05-14 Thread evilant...@gmail.com (JIRA)


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

Anthony Mendonca commented on JENKINS-13737:


I have the same problem on Ubuntu, jenkins1.463 and email-ext 2.20.  I had the 
promotion plugin installed but wasn't using it on any projects.  I also 
uninstalled the promotion plugin and still have this issue.

 Javascript error when selecting Editable Email Notification
 -

 Key: JENKINS-13737
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
 Plugin 2.20
Reporter: Noel Bernardez
Assignee: Slide-O-Mix
  Labels: email-ext, jenkins

 In Jenkins ver. 1.463, when selecting Editable Email Notification in the 
 Add post-build action, getting the following Javascript error 
 Message: 'emailExtInit' is undefined
 Line: 480
 Char: 17
 Code: 0
 URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-13737) Javascript error when selecting Editable Email Notification


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

Slide-O-Mix commented on JENKINS-13737:
---

Yes, this issue will affect ALL users who are using 1.463 regardless of browser 
or OS. It has to do with the change to the dropdown post-build that was put in 
recently. I am in the process of debugging it. It has nothing to do with the 
promotions plugin and everything to do with the version of Jenkins you are 
running. 

 Javascript error when selecting Editable Email Notification
 -

 Key: JENKINS-13737
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
 Plugin 2.20
Reporter: Noel Bernardez
Assignee: Slide-O-Mix
  Labels: email-ext, jenkins

 In Jenkins ver. 1.463, when selecting Editable Email Notification in the 
 Add post-build action, getting the following Javascript error 
 Message: 'emailExtInit' is undefined
 Line: 480
 Char: 17
 Code: 0
 URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

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

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


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

Amir Isfy commented on JENKINS-13227:
-

After I included the .hpi file and restarted Jenkins, it became cvs.jpi and 
cvs.hpi.pinned also became cvs.jpi.pinned but the latter file remained at size 
0. 

 CVS plugin 2.1 does not detect changes
 --

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


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

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

[JIRA] (JENKINS-13607) certain projects can't send email: javax.mail.MessagingException: Could not connect to SMTP host: mail.recondotech.com, port: 25, response: 421

2012-05-14 Thread aslo...@gmail.com (JIRA)


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

Adam Sloan commented on JENKINS-13607:
--

Possibly a local email issue, will add info if I see it again (can close until 
then - a bad day)

 certain projects can't send email: javax.mail.MessagingException: Could not 
 connect to SMTP host: mail.recondotech.com, port: 25, response: 421
 ---

 Key: JENKINS-13607
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13607
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
 /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
 -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
 /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
 --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
 --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
 --handlerCountMaxIdle=20
Reporter: Adam Sloan
  Labels: email, jenkins

 Loss of functionality: emails aren't getting sent out
 Build Console Output:
 Build step 'Execute shell' marked build as failure
 Emma: looking for coverage reports in the provided path: 
 target/site/emma/coverage.xml
 Sending e-mails to: aslo...@gmail.com
 ERROR: Could not connect to SMTP host: mail.recondotech.com, port: 25, 
 response: 421
 javax.mail.MessagingException: Could not connect to SMTP host: 
 mail.recondotech.com, port: 25, response: 421
   at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1922)
   at 
 com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638)
   at javax.mail.Service.connect(Service.java:295)
   at javax.mail.Service.connect(Service.java:176)
   at javax.mail.Service.connect(Service.java:125)
   at javax.mail.Transport.send0(Transport.java:194)
   at javax.mail.Transport.send(Transport.java:124)
   at hudson.tasks.MailSender.execute(MailSender.java:114)
   at 
 hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:1012)
   at hudson.model.Run.run(Run.java:1465)
   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Notifying upstream projects of job completion
 Finished: 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-13264) fail checkout 2 modules with different path

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


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

James Gustafson commented on JENKINS-13264:
---

With the 2.4-SNAPSHOT, I find a need to use a back-slash for the Local Name, 
then it works. For example:

Remote Name: lib/something
Local Name: lib\something

It properly puts the checkout to workspace/project/lib/something. If I set 
Local Name to be lib/something, I get that same error 'No such file or 
directory'... My build server is Windows 7 with the cygpath plug-in if that 
matters. Anyway, it is working for me this way. Thanks Michael.

 fail checkout 2 modules with different path
 ---

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


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

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

[JIRA] (JENKINS-13775) String index out of range

2012-05-14 Thread bee...@163.com (JIRA)

wang y created JENKINS-13775:


 Summary: String index out of range
 Key: JENKINS-13775
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13775
 Project: Jenkins
  Issue Type: Bug
  Components: sloccount
Affects Versions: current
 Environment: Linux:redhat9
jenkins:1.463
Reporter: wang y
Assignee: npiguet


console output:
{quote}
ERROR: Publisher hudson.plugins.sloccount.SloccountPublisher aborted due to 
exception
java.lang.StringIndexOutOfBoundsException: String index out of range: -5
at java.lang.String.substring(String.java:1937)
at java.lang.String.substring(String.java:1904)
at hudson.plugins.sloccount.model.Folder.simplifyName(Folder.java:22)
at 
hudson.plugins.sloccount.model.SloccountReport.simplifyNames(SloccountReport.java:175)
at 
hudson.plugins.sloccount.model.SloccountParser.invoke(SloccountParser.java:42)
at 
hudson.plugins.sloccount.model.SloccountParser.invoke(SloccountParser.java:17)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
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 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{quote}
sloccount file:
{quote}
Have a non-directory at the top, so creating directory top_dir
Adding /g2m_builder_test/railway-svn-code/support/cppcheck-check-Make to top_dir
Adding /g2m_builder_test/railway-svn-code/support/cppcheck_reports.xml to 
top_dir
Adding /g2m_builder_test/railway-svn-code/support/cppcheck-suppress to top_dir
Creating filelist for driver
Adding /g2m_builder_test/railway-svn-code/support/sloccount.sc to top_dir
Creating filelist for test
Categorizing files.
Computing results.


43  ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/GhtDspDisp.c
197 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/GhtDspEnc.c
268 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/GhtDspCap.c
179 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/GhtDspDec.c
87  ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/Convert.c
636 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/dm648api.c
387 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/GhtDspApi.c
173 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/include/dm648api.h
27  ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/include/GhtDspCommon.h
173 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/include/GhtDspApi.h
5   ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/Convert.h
6   ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/SdkVersion.h
240 ansic   test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/ShareStruct.h
37  makefiletest
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/GhtDspApi/Makefile
174 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/dialog/iconDecodeArea.cpp
236 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/dialog/iconPreviewArea.cpp
223 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/dialog/mainWindow.cpp
12  cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/main.cpp
39  cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/public/sunday.cpp
220 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/public/yuv.cpp
143 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/thread/Timer.cpp
41  cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/thread/Thread.cpp
295 cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/video/videoThread.cpp
64  cpp test
/g2m_builder_test/railway-svn-code/support/test/viSdkDialog/video/videoTimer.cpp
445 cpp test

[JIRA] (JENKINS-13170) JellyTagException when clicking on CCM trend chart

2012-05-14 Thread brunodepau...@yahoo.com.br (JIRA)


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

Bruno P. Kinoshita closed JENKINS-13170.


Resolution: Fixed

The graph and other APIs were replaced by analysis-core plug-in. 

 JellyTagException when clicking on CCM trend chart
 --

 Key: JENKINS-13170
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13170
 Project: Jenkins
  Issue Type: Bug
  Components: ccm
Affects Versions: current
 Environment: Ubuntu
Reporter: Samuele Gantner
Assignee: Bruno P. Kinoshita
 Attachments: screenshot.png, stacktrace.txt


 When trying to click on the CCM chart, the resulting page has 500 status code.
 org.apache.commons.jelly.JellyTagException: 
 file:/var/lib/jenkins/plugins/ccm/WEB-INF/classes/hudson/plugins/ccm/CCMProjectAction/nodata.jelly:5:64:
  st:include No page found 'sidepanel.jelly' for class 
 hudson.plugins.ccm.CCMProjectAction
 Exception and screenshots are attached.

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

[JIRA] (JENKINS-13177) CCM result in build shows only top 15 methods even though CCM is configured for 100

2012-05-14 Thread brunodepau...@yahoo.com.br (JIRA)


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

Bruno P. Kinoshita closed JENKINS-13177.


Resolution: Fixed

No user feedback, but the fix has been released in 3.0. Feel free to reopen 
this issue if it is still occurring.

 CCM result in build shows only top 15 methods even though CCM is configured 
 for 100
 ---

 Key: JENKINS-13177
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13177
 Project: Jenkins
  Issue Type: Bug
  Components: ccm
Affects Versions: current
 Environment: Ubuntu master / Windows 7 slave
Reporter: Samuele Gantner
Assignee: Bruno P. Kinoshita
Priority: Minor
 Attachments: result.png, settings.png


 I configured CCM to show 100 methods in Number of metrics. However in the 
 results I only see 15 methods. Screenshots are attached

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

[JIRA] (JENKINS-13621) Serialization issue with TAP consumer


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

SCM/JIRA link daemon commented on JENKINS-13621:


Code changed in jenkins
User: Bruno P. Kinoshita
Path:
 .gitignore
 src/main/java/hudson/plugins/testlink/result/TAPFileNameResultSeeker.java
http://jenkins-ci.org/commit/testlink-plugin/506a7f39e3be19a16aad1969e11b9bd5507da112
Log:
  [FIXED JENKINS-13621] Fixed serialization issues and included test output to 
gitignore




 Serialization issue with TAP consumer
 -

 Key: JENKINS-13621
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13621
 Project: Jenkins
  Issue Type: Bug
  Components: testlink
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita

 Getting the following exception due to serialization problems with a tap 
 consumer:
 FATAL: hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
 hudson.plugins.testlink.result.ResultSeekerException: 
 hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
   at 
 hudson.plugins.testlink.result.TAPFileNameResultSeeker.seek(TAPFileNameResultSeeker.java:176)
   at 
 hudson.plugins.testlink.TestLinkBuilder.perform(TestLinkBuilder.java:159)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:644)
   at hudson.model.Build$RunnerImpl.build(Build.java:175)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:137)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:421)
   at hudson.model.Run.run(Run.java:1362)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:145)
 Caused by: hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
   at hudson.FilePath.act(FilePath.java:753)
   at hudson.FilePath.act(FilePath.java:739)
   at 
 hudson.plugins.testlink.result.TAPFileNameResultSeeker.seek(TAPFileNameResultSeeker.java:129)
   ... 10 more
 Caused by: java.io.IOException: Unable to serialize 
 hudson.FilePath$FileCallableWrapper@4590973e
   at hudson.remoting.UserRequest.serialize(UserRequest.java:162)
   at hudson.remoting.UserRequest.init(UserRequest.java:62)
   at hudson.remoting.Channel.call(Channel.java:629)
   at hudson.FilePath.act(FilePath.java:746)
   ... 12 more
 Caused by: java.io.NotSerializableException: 
 org.tap4j.consumer.TapConsumerImpl
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
   at hudson.remoting.UserRequest._serialize(UserRequest.java:151)
   at hudson.remoting.UserRequest.serialize(UserRequest.java:160)
   ... 15 more
 ERROR: An error occured while trying to retrieve the test results: 
 hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
 Finished: 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-13621) Serialization issue with TAP consumer


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

SCM/JIRA link daemon resolved JENKINS-13621.


Resolution: Fixed

 Serialization issue with TAP consumer
 -

 Key: JENKINS-13621
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13621
 Project: Jenkins
  Issue Type: Bug
  Components: testlink
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita

 Getting the following exception due to serialization problems with a tap 
 consumer:
 FATAL: hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
 hudson.plugins.testlink.result.ResultSeekerException: 
 hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
   at 
 hudson.plugins.testlink.result.TAPFileNameResultSeeker.seek(TAPFileNameResultSeeker.java:176)
   at 
 hudson.plugins.testlink.TestLinkBuilder.perform(TestLinkBuilder.java:159)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:644)
   at hudson.model.Build$RunnerImpl.build(Build.java:175)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:137)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:421)
   at hudson.model.Run.run(Run.java:1362)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:145)
 Caused by: hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
   at hudson.FilePath.act(FilePath.java:753)
   at hudson.FilePath.act(FilePath.java:739)
   at 
 hudson.plugins.testlink.result.TAPFileNameResultSeeker.seek(TAPFileNameResultSeeker.java:129)
   ... 10 more
 Caused by: java.io.IOException: Unable to serialize 
 hudson.FilePath$FileCallableWrapper@4590973e
   at hudson.remoting.UserRequest.serialize(UserRequest.java:162)
   at hudson.remoting.UserRequest.init(UserRequest.java:62)
   at hudson.remoting.Channel.call(Channel.java:629)
   at hudson.FilePath.act(FilePath.java:746)
   ... 12 more
 Caused by: java.io.NotSerializableException: 
 org.tap4j.consumer.TapConsumerImpl
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
   at hudson.remoting.UserRequest._serialize(UserRequest.java:151)
   at hudson.remoting.UserRequest.serialize(UserRequest.java:160)
   ... 15 more
 ERROR: An error occured while trying to retrieve the test results: 
 hudson.util.IOException2: remote file operation failed: 
 /tmp/1/workspace/sample-tap-testlink at hudson.remoting.Channel@6056677a:che
 Finished: 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-13621) Serialization issue with TAP consumer