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

[benjamin.ha...@suncorp.com.au (JIRA)]

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

Benjamin Hahne commented on JENKINS-10484:
--

OK, so I echoed this out to a properties file, then pulled it in with the 
EnvInject plugin (that we're already using), so we do have a bandaid workaround 
until this is fixed.

> SVN_REVISION environment variable is not set when using parameterized 
> Repository URL
> 
>
> Key: JENKINS-10484
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10484
> Project: Jenkins
>  Issue Type: Bug
>  Components: subversion
>Affects Versions: current
> Environment: windows 2003 server, Jenkins 1.421, Subversion Plugin 
> 1.2.8
> RedHat 6.0, Jenkins 1.447.1 LTS, Subversion Plugin 1.40
>Reporter: Erez Harari
>Priority: Critical
>
> I'm using a single Repository URL with parameterized value: 
> ${SVN_URL}/application, where SVN_URL is defined as a node level parameter. 
> in that case SVN_REVISION environment variable is not set.
> When using a clear text Repository URL all works fine.

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

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

[benjamin.ha...@suncorp.com.au (JIRA)]

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

Benjamin Hahne commented on JENKINS-10484:
--

Actually, I retract that as you cannot reference vars set in a script after it 
exits.  :-(

> SVN_REVISION environment variable is not set when using parameterized 
> Repository URL
> 
>
> Key: JENKINS-10484
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10484
> Project: Jenkins
>  Issue Type: Bug
>  Components: subversion
>Affects Versions: current
> Environment: windows 2003 server, Jenkins 1.421, Subversion Plugin 
> 1.2.8
> RedHat 6.0, Jenkins 1.447.1 LTS, Subversion Plugin 1.40
>Reporter: Erez Harari
>Priority: Critical
>
> I'm using a single Repository URL with parameterized value: 
> ${SVN_URL}/application, where SVN_URL is defined as a node level parameter. 
> in that case SVN_REVISION environment variable is not set.
> When using a clear text Repository URL all works fine.

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

[JIRA] (JENKINS-13959) StackOverflowException on Job Finish

[simon.schlach...@ergon.ch (JIRA)]

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

Simon Schlachter updated JENKINS-13959:
---

Attachment: example_fail_config.xml

[Example failing config|^example_fail_config.xml]

> StackOverflowException on Job Finish
> 
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
> Attachments: example_fail_config.xml
>
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following 
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
>   at 
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
>   at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
>   at java.util.Calendar.updateTime(Calendar.java:2495)
>   at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
>   at java.util.Calendar.getMillisOf(Calendar.java:2512)
>   at java.util.Calendar.equals(Calendar.java:1892)
>   at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report 
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email 
> notification" setting, storing the configuration and then re-add the 
> notification setting, so perhaps it has something to do with the notification 
> part in jenkins itself.
> PS: The concerned Jobs do not all use CVS, some of them are git-only but get 
> the exact same stacktrace as reported above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact 

[JIRA] (JENKINS-13981) Adding configuration file validation for weblogic-deployer-plugin

[r...@orange.fr (JIRA)]

Raphael CHAUMIER created JENKINS-13981:
--

 Summary: Adding configuration file validation for 
weblogic-deployer-plugin 
 Key: JENKINS-13981
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13981
 Project: Jenkins
  Issue Type: Improvement
  Components: plugin
Reporter: Raphael CHAUMIER
Assignee: Raphael CHAUMIER
Priority: Trivial




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

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

[benjamin.ha...@suncorp.com.au (JIRA)]

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

Benjamin Hahne updated JENKINS-10484:
-

Environment: 
windows 2003 server, Jenkins 1.421, Subversion Plugin 1.2.8
RedHat 6.0, Jenkins 1.447.1 LTS, Subversion Plugin 1.40

  was:windows 2003 server, Jenkins 1.421, Subversion Plugin 1.2.8


Added RedHat 6 to affected environments.
Currently working around with script build step containing
{code}export SVN_REVISION=$(svn info | grep Revision | sed -e 's|.*:\ ||'){code}

> SVN_REVISION environment variable is not set when using parameterized 
> Repository URL
> 
>
> Key: JENKINS-10484
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10484
> Project: Jenkins
>  Issue Type: Bug
>  Components: subversion
>Affects Versions: current
> Environment: windows 2003 server, Jenkins 1.421, Subversion Plugin 
> 1.2.8
> RedHat 6.0, Jenkins 1.447.1 LTS, Subversion Plugin 1.40
>Reporter: Erez Harari
>Priority: Critical
>
> I'm using a single Repository URL with parameterized value: 
> ${SVN_URL}/application, where SVN_URL is defined as a node level parameter. 
> in that case SVN_REVISION environment variable is not set.
> When using a clear text Repository URL all works fine.

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

[JIRA] (JENKINS-13980) The archive folder gets lost if you also backup archives for builds

[tofuatj...@java.net (JIRA)]

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

Thomas Fürer updated JENKINS-13980:
---

Description: 
builds
 >> 2000-01-01_00-00-00
  >>> archive
 artifact.jar
  >>> changelog.xml
  >>> ..

will be backuped and restored in

builds
 >> 2000-01-01_00-00-00
  >>> artifact.jar
  >>> changelog.xml
  >>> ..


  was:
builds
 > 2000-01-01_00-00-00
  > archive
> artifact.jar
  > changelog.xml
  > ..

will be backuped and restored in

builds
 > 2000-01-01_00-00-00
  > artifact.jar
  > changelog.xml
  > ..



> The archive folder gets lost if you also backup archives for builds
> ---
>
> Key: JENKINS-13980
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13980
> Project: Jenkins
>  Issue Type: Bug
>  Components: thinBackup
>Reporter: Thomas Fürer
>Assignee: Thomas Fürer
>Priority: Critical
>
> builds
>  >> 2000-01-01_00-00-00
>   >>> archive
>  artifact.jar
>   >>> changelog.xml
>   >>> ..
> will be backuped and restored in
> builds
>  >> 2000-01-01_00-00-00
>   >>> artifact.jar
>   >>> changelog.xml
>   >>> ..

--
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-13980) The archive folder gets lost if you also backup archives for builds

[tofuatj...@java.net (JIRA)]

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

Thomas Fürer updated JENKINS-13980:
---

Description: 
builds
 > 2000-01-01_00-00-00
  > archive
> artifact.jar
  > changelog.xml
  > ..

will be backuped and restored in

builds
 > 2000-01-01_00-00-00
  > artifact.jar
  > changelog.xml
  > ..


  was:
builds
 - 2000-01-01_00-00-00
  - archive
- artifact.jar
  - changelog.xml
  - ..

will be backuped and restored in

builds
 - 2000-01-01_00-00-00
  - artifact.jar
  - changelog.xml
  - ..



> The archive folder gets lost if you also backup archives for builds
> ---
>
> Key: JENKINS-13980
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13980
> Project: Jenkins
>  Issue Type: Bug
>  Components: thinBackup
>Reporter: Thomas Fürer
>Assignee: Thomas Fürer
>Priority: Critical
>
> builds
>  > 2000-01-01_00-00-00
>   > archive
> > artifact.jar
>   > changelog.xml
>   > ..
> will be backuped and restored in
> builds
>  > 2000-01-01_00-00-00
>   > artifact.jar
>   > changelog.xml
>   > ..

--
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-13980) The archive folder gets lost if you also backup archives for builds

[tofuatj...@java.net (JIRA)]

Thomas Fürer created JENKINS-13980:
--

 Summary: The archive folder gets lost if you also backup archives 
for builds
 Key: JENKINS-13980
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13980
 Project: Jenkins
  Issue Type: Bug
  Components: thinBackup
Reporter: Thomas Fürer
Assignee: Thomas Fürer
Priority: Critical


builds
 - 2000-01-01_00-00-00
  - archive
- artifact.jar
  - changelog.xml
  - ..

will be backuped and restored in

builds
 - 2000-01-01_00-00-00
  - artifact.jar
  - changelog.xml
  - ..


--
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-13976) Allow backslash-escaped line terminators in content token string arguments

[sar...@syr.edu (JIRA)]

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

Steve Rowe updated JENKINS-13976:
-

Summary: Allow backslash-escaped line terminators in content token string 
arguments  (was: Allow content token arguments to contain line terminators)

> Allow backslash-escaped line terminators in content token string arguments
> --
>
> Key: JENKINS-13976
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13976
> Project: Jenkins
>  Issue Type: Improvement
>  Components: email-ext
>Reporter: Steve Rowe
>Assignee: Slide-O-Mix
>Priority: Minor
>
> The {{stringRegex}} field in {{ContentBuilder.Tokenizer}} disallows line 
> terminators in content token arguments (see [line #141 in 
> ContentBuilder.java|https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L141]):
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator
> private static final String stringRegex = "\"([^\"\\r\\n]|(.))*\"";
> {code}
> I propose allowing *escaped* line terminators, in the tradition of using 
> backslashes as line continuation characters in various scripting languages, 
> including Bash and Python:
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF 
> character or (CR)LF
> private static final String stringRegex = 
> "\"([^\"\\r\\n]|((?:.|\r?\n)))*\"";
> {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-13976) Allow content token arguments to contain line terminators

[sar...@syr.edu (JIRA)]

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

Steve Rowe commented on JENKINS-13976:
--

Done: https://github.com/jenkinsci/email-ext-plugin/pull/39

> Allow content token arguments to contain line terminators
> -
>
> Key: JENKINS-13976
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13976
> Project: Jenkins
>  Issue Type: Improvement
>  Components: email-ext
>Reporter: Steve Rowe
>Assignee: Slide-O-Mix
>Priority: Minor
>
> The {{stringRegex}} field in {{ContentBuilder.Tokenizer}} disallows line 
> terminators in content token arguments (see [line #141 in 
> ContentBuilder.java|https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L141]):
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator
> private static final String stringRegex = "\"([^\"\\r\\n]|(.))*\"";
> {code}
> I propose allowing *escaped* line terminators, in the tradition of using 
> backslashes as line continuation characters in various scripting languages, 
> including Bash and Python:
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF 
> character or (CR)LF
> private static final String stringRegex = 
> "\"([^\"\\r\\n]|((?:.|\r?\n)))*\"";
> {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-13979) [scriptler plugin]build failed if groovy script return false.

[hayato_1...@yahoo.co.jp (JIRA)]

Hayato Ito created JENKINS-13979:


 Summary: [scriptler plugin]build failed if groovy script return 
false.
 Key: JENKINS-13979
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13979
 Project: Jenkins
  Issue Type: New Feature
  Components: scriptler
Reporter: Hayato Ito
Assignee: domi
 Fix For: current


background:

I want to run some checking script on scriptler plugin.
ex) disk usage check, file exists check, network connectivity test...

but, scriptler plugin does not have method to fail to job except throwing a 
exception.
If throw exception in the script, the script output is not to print console log.

feature:

- build fail if the scriptler script return false.


--
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-13934) Make it possible to delete all except latest 'n' archived artifacts

[ohtake_tomoh...@java.net (JIRA)]

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

OHTAKE Tomohiro resolved JENKINS-13934.
---

Resolution: Not A Defect

> Make it possible to delete all except latest 'n' archived artifacts
> ---
>
> Key: JENKINS-13934
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13934
> Project: Jenkins
>  Issue Type: Improvement
>  Components: postbuild-task
>Affects Versions: current
> Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466
>Reporter: Paul Croome
>Assignee: OHTAKE Tomohiro
>Priority: Minor
> Attachments: Max_number_of_builds_to_keep_with_artifacts.png
>
>
> In the job configuration page, under Post-build Actions > Archive the 
> Artifacts > Advanced
> it's possible to select the checkbox "Discard all but the last 
> successful/stable artifact to save disk space".
> It would be useful if I could choose "Discard all but the last 'n' 
> successful/stable artifacts to save disk space".
> (By comparison: The option "Discard Old Builds" allows me to specify "Max # 
> of builds to keep". A similar feature for archived artifacts would be nice.)

--
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-13977) Broken breadcrumb link drops me on contextMenu

[ohtake_tomoh...@java.net (JIRA)]

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

OHTAKE Tomohiro commented on JENKINS-13977:
---

The issue has been resolved in Jenkins 1.456.
See 
[5301b262327e685251e786ea0176a11b4bd994a4|https://github.com/jenkinsci/jenkins/commit/5301b262327e685251e786ea0176a11b4bd994a4].

> Broken breadcrumb link drops me on contextMenu
> --
>
> Key: JENKINS-13977
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13977
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Reporter: R. Tyler Croy
>Priority: Minor
>
> On a console page such as {{https://ci.lan/job/jobname/1472/console}} if I go 
> to the "#1472" breadcrumb and click on "Previous Build" or "Next Build" then 
> I land on {{https://ci.lan/job/jobname/1471/contextMenu}}

--
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-13972) Concurrent matrix builds abort

[jkoles...@google.com (JIRA)]

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

John Koleszar commented on JENKINS-13972:
-

I was able to reproduce this by hacking one of Jenkins' unit tests as well:
{noformat}
diff --git 
a/test/src/test/groovy/hudson/matrix/MatrixProjectCustomWorkspaceTest.groovy 
b/test/src/test/groovy/hudson/matrix/MatrixProjectCustomWorkspaceTest.groovy
index 1ddb195..8b6f324 100644
--- a/test/src/test/groovy/hudson/matrix/MatrixProjectCustomWorkspaceTest.groovy
+++ b/test/src/test/groovy/hudson/matrix/MatrixProjectCustomWorkspaceTest.groovy
@@ -116,7 +116,7 @@ class MatrixProjectCustomWorkspaceTest extends 
HudsonTestCase {
  */
 def configureCustomWorkspaceConcurrentBuild(MatrixProject p) {
 // needs sufficient parallel execution capability
-jenkins.numExecutors = 10
+jenkins.numExecutors = 4
 jenkins.updateComputerList()
 
 p.axes = new AxisList(new TextAxis("foo", "1", "2"))
@@ -140,8 +140,10 @@ class MatrixProjectCustomWorkspaceTest extends 
HudsonTestCase {
 // get one going
 Thread.sleep(1000)
 def f2 = p.scheduleBuild2(0)
+Thread.sleep(1000)
+def f3 = p.scheduleBuild2(0)
 
-def bs = [f1, f2]*.get().each { assertBuildStatusSuccess(it) }
+def bs = [f1, f2, f3]*.get().each { assertBuildStatusSuccess(it) }
 return bs
 }
 }

{noformat}

> Concurrent matrix builds abort
> --
>
> Key: JENKINS-13972
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13972
> Project: Jenkins
>  Issue Type: Bug
>  Components: concurrent-build
>Affects Versions: current
>Reporter: John Koleszar
>Assignee: Kohsuke Kawaguchi
>Priority: Minor
>
> Reproduction case:
> Create a concurrent matrix job with a user defined axis that does a 'sleep 
> 120' as its build step. Launch several of these jobs, enough that all 
> available executors are taken up and there are still builds in the queue. 
> Some of these builds will abort, with a console message similar to:
> [...]
> 9 completed with result SUCCESS
> 24 completed with result SUCCESS
> 23 completed with result SUCCESS
> 2 completed with result SUCCESS
> 10 appears to be cancelled
> 10 completed with result ABORTED
> 25 appears to be cancelled
> 25 completed with result ABORTED
> 18 appears to be cancelled
> 18 completed with result ABORTED
> 13 appears to be cancelled
> [...]
> For my test case, I have 26 slaves, 82 executors, 25 sub-jobs. I can 
> reproduce reliably if I launch 5 or more top level jobs at once.

--
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-13978) Add posibility to copy view

[pess...@seznam.cz (JIRA)]

Peter Kolínek created JENKINS-13978:
---

 Summary: Add posibility to copy view
 Key: JENKINS-13978
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13978
 Project: Jenkins
  Issue Type: Improvement
  Components: gui
Reporter: Peter Kolínek
Priority: Minor


When creating a new view, there could be an option to copy already existing 
view - the same way it is when new project is created.

--
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-13330) Jenkins slave hangs in post build phase

[k...@kohsuke.org (JIRA)]

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

Kohsuke Kawaguchi commented on JENKINS-13330:
-

#2284 is waiting for the shell script build step to complete. Later builds are 
past that point, but those are blocked at the point of e-mail notification, 
waiting for the previous build to complete (or else it won't be able to decide 
what to send out in the e-mail.)

So at this point, my reading of this is that this is not a bug in Jenkins but 
simply a hang in the user script, but if you suspect otherwise, please wait for 
the next hang to occur, then obtain the thread dump both on the master and the 
slave, and check what the first blocked build is doing.

As I've explained above, concurrent executions of the same job can block if the 
earlier build is blocked, so we need to focus on the root cause, which is why 
the first of the blocked builds is blocking.

> Jenkins slave hangs in post build phase
> ---
>
> Key: JENKINS-13330
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13330
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave, slave-status
> Environment: RHEL 5, both master and all slaves.
> Jenkins is running inside of Tomcat
>Reporter: Clark Wright
>Priority: Critical
> Attachments: jenkins-stall-threaddump.gz, 
> jenkins-stall-threaddump.gz, Screenshot-galleon_allIntegration #1196 Console 
> [Jenkins] - Mozilla Firefox.png
>
>
> We have an intermittent problem with slaves hanging AFTER the job itself is 
> finished. In the post processing step (?) what we see is that the console log 
> has this line:
> Description set: vap_current_iter-2012_03_29_19_01_03
> And then nothing. Usually, it will look like this:
> Description set: prod_pull-2012_03_28_19_01_03
> Notifying upstream build armada_Launch_prod_pull #13 of job completion
> Project armada_Launch_prod_pull still waiting for 1 builds to complete
> Notifying upstream projects of job completion
> Notifying upstream of completion: armada_Launch_prod_pull #13
> Finished: SUCCESS
> I setup a logger for hudson.model.Run, and it currently has this :
> {noformat}
> at java.lang.Thread.run(Thread.java:619)
> Mar 30, 2012 12:44:00 PM hudson.model.Run run
> INFO: galleon_allUnit #1134 main build action completed: SUCCESS
> Mar 30, 2012 12:44:00 PM hudson.model.Run setResult
> FINE: galleon_allUnit #1134 : result is set to SUCCESS
> java.lang.Exception
> at hudson.model.Run.setResult(Run.java:352)
> at hudson.model.Run.run(Run.java:1410)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> {noformat}
> Repeated for every hung slave.
> The main hudson log doesn't have any additional information.
> Disconnecting the slave has no effect.
> Trying to do an orderly shutdown of Jenkins has no effect (jenkins actually 
> appears to hang on shutdown).
> The only way we have found to recover is to kill -9 the tomcat process.
> The tread dump for one of the slaves (they are all the same) is:
> {noformat}
> Thread Dump
> Channel reader thread: channel
> "Channel reader thread: channel" Id=9 Group=main RUNNABLE (in native)
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:199)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
> -  locked java.io.BufferedInputStream@1ae615a
> 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:1030)
> main
> "main" Id=1 Group=main WAITING on hudson.remoting.Channel@e1d5ea
> at java.lang.Object.wait(Native Method)
> -  waiting on hudson.remoting.Channel@e1d5ea
> at java.lang.Object.wait(Object.java:485)
> at hudson.remoting.Channel.join(Channel.java:766)
> at hudson.remoting.Launcher.main(Launcher.java:420)
> at hudson.remoting.Launcher.runWithStdinStdout(Launcher.java:366)
> at hudson.remoting.Launcher.run(Launcher.java:206)
> at hudson.remoting.Launcher.main(Launcher.java:168)
> Ping thread for channel hudson.remoting.Channel@e1d5ea:channel
> "Ping thread for channel hudson.remoting.Channel@e1d5ea:channel" Id=10 
> Group=main 

[JIRA] (JENKINS-13330) Jenkins slave hangs in post build phase

[k...@kohsuke.org (JIRA)]

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

Kohsuke Kawaguchi commented on JENKINS-13330:
-

In the thread dump, #2284 is waiting for the build to complete, then later 
concurrent builds are waiting for that to finish before it sends out its 
failure notification.

> Jenkins slave hangs in post build phase
> ---
>
> Key: JENKINS-13330
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13330
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave, slave-status
> Environment: RHEL 5, both master and all slaves.
> Jenkins is running inside of Tomcat
>Reporter: Clark Wright
>Priority: Critical
> Attachments: jenkins-stall-threaddump.gz, 
> jenkins-stall-threaddump.gz, Screenshot-galleon_allIntegration #1196 Console 
> [Jenkins] - Mozilla Firefox.png
>
>
> We have an intermittent problem with slaves hanging AFTER the job itself is 
> finished. In the post processing step (?) what we see is that the console log 
> has this line:
> Description set: vap_current_iter-2012_03_29_19_01_03
> And then nothing. Usually, it will look like this:
> Description set: prod_pull-2012_03_28_19_01_03
> Notifying upstream build armada_Launch_prod_pull #13 of job completion
> Project armada_Launch_prod_pull still waiting for 1 builds to complete
> Notifying upstream projects of job completion
> Notifying upstream of completion: armada_Launch_prod_pull #13
> Finished: SUCCESS
> I setup a logger for hudson.model.Run, and it currently has this :
> {noformat}
> at java.lang.Thread.run(Thread.java:619)
> Mar 30, 2012 12:44:00 PM hudson.model.Run run
> INFO: galleon_allUnit #1134 main build action completed: SUCCESS
> Mar 30, 2012 12:44:00 PM hudson.model.Run setResult
> FINE: galleon_allUnit #1134 : result is set to SUCCESS
> java.lang.Exception
> at hudson.model.Run.setResult(Run.java:352)
> at hudson.model.Run.run(Run.java:1410)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> {noformat}
> Repeated for every hung slave.
> The main hudson log doesn't have any additional information.
> Disconnecting the slave has no effect.
> Trying to do an orderly shutdown of Jenkins has no effect (jenkins actually 
> appears to hang on shutdown).
> The only way we have found to recover is to kill -9 the tomcat process.
> The tread dump for one of the slaves (they are all the same) is:
> {noformat}
> Thread Dump
> Channel reader thread: channel
> "Channel reader thread: channel" Id=9 Group=main RUNNABLE (in native)
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:199)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
> -  locked java.io.BufferedInputStream@1ae615a
> 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:1030)
> main
> "main" Id=1 Group=main WAITING on hudson.remoting.Channel@e1d5ea
> at java.lang.Object.wait(Native Method)
> -  waiting on hudson.remoting.Channel@e1d5ea
> at java.lang.Object.wait(Object.java:485)
> at hudson.remoting.Channel.join(Channel.java:766)
> at hudson.remoting.Launcher.main(Launcher.java:420)
> at hudson.remoting.Launcher.runWithStdinStdout(Launcher.java:366)
> at hudson.remoting.Launcher.run(Launcher.java:206)
> at hudson.remoting.Launcher.main(Launcher.java:168)
> Ping thread for channel hudson.remoting.Channel@e1d5ea:channel
> "Ping thread for channel hudson.remoting.Channel@e1d5ea:channel" Id=10 
> Group=main TIMED_WAITING
> at java.lang.Thread.sleep(Native Method)
> at hudson.remoting.PingThread.run(PingThread.java:86)
> Pipe writer thread: channel
> "Pipe writer thread: channel" Id=12 Group=main WAITING on 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@14263ed
> at sun.misc.Unsafe.park(Native Method)
> -  waiting on 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@14263ed
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(

[JIRA] (JENKINS-13330) Jenkins slave hangs in post build phase

[k...@kohsuke.org (JIRA)]

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

Kohsuke Kawaguchi updated JENKINS-13330:


Description: 
We have an intermittent problem with slaves hanging AFTER the job itself is 
finished. In the post processing step (?) what we see is that the console log 
has this line:

Description set: vap_current_iter-2012_03_29_19_01_03

And then nothing. Usually, it will look like this:

Description set: prod_pull-2012_03_28_19_01_03
Notifying upstream build armada_Launch_prod_pull #13 of job completion
Project armada_Launch_prod_pull still waiting for 1 builds to complete
Notifying upstream projects of job completion
Notifying upstream of completion: armada_Launch_prod_pull #13
Finished: SUCCESS

I setup a logger for hudson.model.Run, and it currently has this :

{noformat}
at java.lang.Thread.run(Thread.java:619)

Mar 30, 2012 12:44:00 PM hudson.model.Run run
INFO: galleon_allUnit #1134 main build action completed: SUCCESS
Mar 30, 2012 12:44:00 PM hudson.model.Run setResult
FINE: galleon_allUnit #1134 : result is set to SUCCESS
java.lang.Exception
at hudson.model.Run.setResult(Run.java:352)
at hudson.model.Run.run(Run.java:1410)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
{noformat}

Repeated for every hung slave.

The main hudson log doesn't have any additional information.

Disconnecting the slave has no effect.

Trying to do an orderly shutdown of Jenkins has no effect (jenkins actually 
appears to hang on shutdown).

The only way we have found to recover is to kill -9 the tomcat process.

The tread dump for one of the slaves (they are all the same) is:

{noformat}
Thread Dump
Channel reader thread: channel

"Channel reader thread: channel" Id=9 Group=main RUNNABLE (in native)
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:199)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
-  locked java.io.BufferedInputStream@1ae615a
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:1030)


main

"main" Id=1 Group=main WAITING on hudson.remoting.Channel@e1d5ea
at java.lang.Object.wait(Native Method)
-  waiting on hudson.remoting.Channel@e1d5ea
at java.lang.Object.wait(Object.java:485)
at hudson.remoting.Channel.join(Channel.java:766)
at hudson.remoting.Launcher.main(Launcher.java:420)
at hudson.remoting.Launcher.runWithStdinStdout(Launcher.java:366)
at hudson.remoting.Launcher.run(Launcher.java:206)
at hudson.remoting.Launcher.main(Launcher.java:168)


Ping thread for channel hudson.remoting.Channel@e1d5ea:channel

"Ping thread for channel hudson.remoting.Channel@e1d5ea:channel" Id=10 
Group=main TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at hudson.remoting.PingThread.run(PingThread.java:86)


Pipe writer thread: channel

"Pipe writer thread: channel" Id=12 Group=main WAITING on 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@14263ed
at sun.misc.Unsafe.park(Native Method)
-  waiting on 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@14263ed
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)


pool-1-thread-267

"pool-1-thread-267" Id=285 Group=main RUNNABLE
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:374)
at hudson.Functions.getThreadInfos(Functions.java:872)
at 
hudson.util.RemotingDiagnostics$GetThreadDump.call(RemotingDiagnostics.java:93)
at 
hudson.util.RemotingDiagnostics$GetThreadDump.call(RemotingDiagnostics.java:89)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Execu

[JIRA] (JENKINS-13977) Broken breadcrumb link drops me on contextMenu

[ty...@monkeypox.org (JIRA)]

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

R. Tyler Croy commented on JENKINS-13977:
-

This is on 1.455 fwiw

> Broken breadcrumb link drops me on contextMenu
> --
>
> Key: JENKINS-13977
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13977
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Reporter: R. Tyler Croy
>Priority: Minor
>
> On a console page such as {{https://ci.lan/job/jobname/1472/console}} if I go 
> to the "#1472" breadcrumb and click on "Previous Build" or "Next Build" then 
> I land on {{https://ci.lan/job/jobname/1471/contextMenu}}

--
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-13977) Broken breadcrumb link drops me on contextMenu

[ty...@monkeypox.org (JIRA)]

R. Tyler Croy created JENKINS-13977:
---

 Summary: Broken breadcrumb link drops me on contextMenu
 Key: JENKINS-13977
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13977
 Project: Jenkins
  Issue Type: Bug
  Components: core
Reporter: R. Tyler Croy
Priority: Minor


On a console page such as {{https://ci.lan/job/jobname/1472/console}} if I go 
to the "#1472" breadcrumb and click on "Previous Build" or "Next Build" then I 
land on {{https://ci.lan/job/jobname/1471/contextMenu}}

--
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-13976) Allow content token arguments to contain line terminators

[sar...@syr.edu (JIRA)]

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

Steve Rowe commented on JENKINS-13976:
--

Okay, will do.

> Allow content token arguments to contain line terminators
> -
>
> Key: JENKINS-13976
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13976
> Project: Jenkins
>  Issue Type: Improvement
>  Components: email-ext
>Reporter: Steve Rowe
>Assignee: Slide-O-Mix
>Priority: Minor
>
> The {{stringRegex}} field in {{ContentBuilder.Tokenizer}} disallows line 
> terminators in content token arguments (see [line #141 in 
> ContentBuilder.java|https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L141]):
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator
> private static final String stringRegex = "\"([^\"\\r\\n]|(.))*\"";
> {code}
> I propose allowing *escaped* line terminators, in the tradition of using 
> backslashes as line continuation characters in various scripting languages, 
> including Bash and Python:
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF 
> character or (CR)LF
> private static final String stringRegex = 
> "\"([^\"\\r\\n]|((?:.|\r?\n)))*\"";
> {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-13976) Allow content token arguments to contain line terminators

[slide.o....@gmail.com (JIRA)]

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

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

Feel free to fork and submit a pull request. That would be the quickest way to 
get this in as I am working on some other features/debug right now.

> Allow content token arguments to contain line terminators
> -
>
> Key: JENKINS-13976
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13976
> Project: Jenkins
>  Issue Type: Improvement
>  Components: email-ext
>Reporter: Steve Rowe
>Assignee: Slide-O-Mix
>Priority: Minor
>
> The {{stringRegex}} field in {{ContentBuilder.Tokenizer}} disallows line 
> terminators in content token arguments (see [line #141 in 
> ContentBuilder.java|https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L141]):
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator
> private static final String stringRegex = "\"([^\"\\r\\n]|(.))*\"";
> {code}
> I propose allowing *escaped* line terminators, in the tradition of using 
> backslashes as line continuation characters in various scripting languages, 
> including Bash and Python:
> {code:java}
> // Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF 
> character or (CR)LF
> private static final String stringRegex = 
> "\"([^\"\\r\\n]|((?:.|\r?\n)))*\"";
> {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-13976) Allow content token arguments to contain line terminators

[sar...@syr.edu (JIRA)]

Steve Rowe created JENKINS-13976:


 Summary: Allow content token arguments to contain line terminators
 Key: JENKINS-13976
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13976
 Project: Jenkins
  Issue Type: Improvement
  Components: email-ext
Reporter: Steve Rowe
Assignee: Slide-O-Mix
Priority: Minor


The {{stringRegex}} field in {{ContentBuilder.Tokenizer}} disallows line 
terminators in content token arguments (see [line #141 in 
ContentBuilder.java|https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L141]):

{code:java}
// Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator

private static final String stringRegex = "\"([^\"\\r\\n]|(.))*\"";
{code}

I propose allowing *escaped* line terminators, in the tradition of using 
backslashes as line continuation characters in various scripting languages, 
including Bash and Python:

{code:java}
// Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF character 
or (CR)LF
private static final String stringRegex = 
"\"([^\"\\r\\n]|((?:.|\r?\n)))*\"";
{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-2058) success even when archive artifact java error

[jos...@java.net (JIRA)]

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

Jose Sa commented on JENKINS-2058:
--

Here is another stack trace. This was running directly in the Master on a 
Solaris 10 sparc with jdk1.6.0_19

{code}
Archiving artifacts
ERROR: Failed to archive artifacts: build.cs,CD_STAGE/*.nar*
hudson.util.IOException2: Failed to copy 
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/workspace/build.cs,CD_STAGE/*.nar* to 
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/builds/2012-05-31_12-11-08/archive
at hudson.FilePath$34.invoke(FilePath.java:1689)
at hudson.FilePath$34.invoke(FilePath.java:1656)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1656)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at 
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
at hudson.model.Run.run(Run.java:1438)
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: Failed to copy 
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/workspace/CD_STAGE/NAdM_2.0_OES_UPDATE-119-001.nar
 to 
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/builds/2012-05-31_12-11-08/archive/CD_STAGE/NAdM_2.0_OES_UPDATE-119-001.nar
 due to Map failed
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:914)
at hudson.FilePath$34$1CopyImpl.doFileOperations(FilePath.java:1672)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:567)
at hudson.FilePath$34.invoke(FilePath.java:1686)
... 15 more
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:758)
at 
sun.nio.ch.FileChannelImpl.transferFromFileChannel(FileChannelImpl.java:537)
at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:600)
at 
org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:532)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559)
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:899)
... 18 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:755)
... 23 more
Triggering a new build of NAdM2_SP1_ISO_LV1 #27
Notifying upstream projects of job completion
Finished: SUCCESS
{code}

> success even when archive artifact java error
> -
>
> Key: JENKINS-2058
> URL: https://issues.jenkins-ci.org/browse/JENKINS-2058
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave
>Affects Versions: current
> Environment: Platform: All, OS: Solaris
>Reporter: bll
>
> Been having some troubles w/archive artifacts hanging from a linux master 
> (java
> 1.6) to solaris slave (java 1.5).  Here's an instance where it actually got an
> error, but reported success.
> The hanging issue seems to be intermittent.  It completed a job not long ago.
> ERROR: Failed to archive artifacts: repoName, prevent-dev/version, build.log,
> lastPush, prevent-dev/objs/**/*.tar.gz, prevent-dev/objs/**/*.map.gz,
> prevent-dev/objs/**/cov-generate-hostid-*
> hudson.util.IOException2: Failed to read the remote stream
> /hudson_home/workspace/prevent-dev.solaris-x86/repoName, prevent-dev/version,
> build.log, lastPush, prevent-dev/objs/**/*.tar.gz, 
> prevent-dev/objs/**/*.map.gz,
> prevent-dev/objs/**/cov-generate-hostid-*
>   at hudson.FilePath.readFromTar(FilePath.java:922)
>   at hudson.FilePath.copyRecursiveTo(FilePath.java:846)
>   at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:78)
>   at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:309)
>   at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:297)
>   at hudson.model.Build$RunnerImpl.post2(Build.java:118)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:282)
>   at hudson.model.Run.run(Run.java:796)
>   at hudson.model.Build.run(Build.java:85)
>   at hudson.model.Resourc

[JIRA] (JENKINS-2460) Allow branch option on cvs tag

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke reassigned JENKINS-2460:
---

Assignee: Michael Clarke  (was: Kohsuke Kawaguchi)

> Allow branch option on cvs tag
> --
>
> Key: JENKINS-2460
> URL: https://issues.jenkins-ci.org/browse/JENKINS-2460
> Project: Jenkins
>  Issue Type: Improvement
>  Components: cvs
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: gdlloyd
>Assignee: Michael Clarke
>
> Please could you add the enhancement to select (tick box perhaps?) rather 
> create
> a cvs branch when selecting the build option "Tag this 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-13734) CVS plugin crashes Maven release builds with the error "Cannot prepare the release because you have local modifications"

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13734:
--

Can we get some details on your job config: are you building on a 
branch/tag/head, and are you using 'update' or 'checkout'? If possible, attach 
your config.xml for your job (obscure any sensitive values) so I can try and 
replicate your setup.

> CVS plugin crashes Maven release builds with the error "Cannot prepare the 
> release because you have local modifications"
> 
>
> Key: JENKINS-13734
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13734
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs
>Affects Versions: current
> Environment: CentOS, Jenkins 1.463, CVS plugin 2.3, Jenkins Maven 
> Release Plugin 0.9.1
>Reporter: Sergey Skladchikov
>  Labels: cvs, maven, plugin, release
> Attachments: log
>
>
> 1. Install Jenkins Maven Release Plugin 0.9.1
> 2. Make a new project and add the pom.xml file containing the following 
> settings:
> {code:xml}
> ...
> 
> 
> scm:cvs:pserver:CVS-ACCOUNT:PASSWORD@CVS-SERVER:/REPOSITORY:MODULE
> 
> ...
> 
> 
> 
> maven
> maven-scm-plugin
> 1.6.1
> 
> 
> org.apache.maven.plugins
> maven-release-plugin
> 2.2.2
> 
>false
> 
> 
> 
> 
> ...
> 
> 
> my-releases
> 
> ANY_RELEASES_REPOSITORY_URL
> 
> 
> ...
> {code}
> 3. Import the project into your CVS server
> 4. Create a new maven job and specify all the necessary CVS connection 
> settings
> 5. Open the job page and click the link "Perform Maven Release"
> Expected: the job compiles the project and publishes a newly created artefact
> Actual: the job is crushed with the error "Cannot prepare the release because 
> you have local modifications" (see attachments for details)
> Important note: everything works properly if I use CVS plugin version 1.6

--
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-12104) cvs-plugin doesn't catch file changes if the files are checked out with -f -r (HEAD or branch)

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke resolved JENKINS-12104.
--

Resolution: Fixed

This should be resolved in the latest snapshot with the fixes for failing to 
poll or recognise changes on branches

> cvs-plugin doesn't catch file changes if the files are checked out with -f -r 
> (HEAD or branch)
> --
>
> Key: JENKINS-12104
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12104
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs
> Environment: suse linux, java 1.6.0-30, Jenkins 1.443, cvs-plugin 1.6
>Reporter: Alex Lehmann
>Assignee: Michael Clarke
>Priority: Minor
> Fix For: current
>
>
> When checking out a cvs repository with Branch and Use HEAD revision if tag 
> not found, the Changes list is always empty even though the build was 
> triggered by scm changes that are picked up the by cvs update in the build 
> log.
> Since the use Head function was introduced by me in 1.5, maybe the update 
> check is broken in a way I didn't notice, I will try to fix this.

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

[JIRA] (JENKINS-11760) Failed SCM poll does not notify admin/anyone of failure.

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke updated JENKINS-11760:
-

   Priority: Minor  (was: Major)
Component/s: (was: cvs)

As this is SCM independent (a failed poll acts the same for all SCM plugins), 
I'm removing the specific tag for CVS

> Failed SCM poll does not notify admin/anyone of failure.
> 
>
> Key: JENKINS-11760
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11760
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: CentOS 6.0 Master OS x64 x86_64, Jenkins 1.439
>Reporter: Sagar Khushalani
>Priority: Minor
>
> If a particular line in the "Excluded Regions" of is a bad regex, polling 
> fails with the following. However, it does not send an email, or notify the 
> admin in any way. Would it be possible to either send an email (or otherwise 
> notify), or cause the build to fail so the admin can check on it?
> Thanks!
> {noformat}
> ERROR: Failed to record SCM polling
> java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence 
> near index 3
> .*\CVS
>^
>   at java.util.regex.Pattern.error(Pattern.java:1730)
>   at java.util.regex.Pattern.escape(Pattern.java:2194)
>   at java.util.regex.Pattern.atom(Pattern.java:1969)
>   at java.util.regex.Pattern.sequence(Pattern.java:1851)
>   at java.util.regex.Pattern.expr(Pattern.java:1769)
>   at java.util.regex.Pattern.compile(Pattern.java:1477)
>   at java.util.regex.Pattern.(Pattern.java:1150)
>   at java.util.regex.Pattern.compile(Pattern.java:840)
>   at hudson.scm.CVSSCM.getExcludedRegionsPatterns(CVSSCM.java:316)
>   at hudson.scm.CVSSCM.compareRemoteRevisionWith(CVSSCM.java:205)
>   at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
>   at hudson.scm.SCM.poll(SCM.java:373)
>   at hudson.model.AbstractProject.poll(AbstractProject.java:1313)
>   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:471)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>   at java.lang.Thread.run(Thread.java:636)
> {noformat}

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

[JIRA] (JENKINS-4898) Poll SCM trigger mechanism

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke updated JENKINS-4898:


Component/s: (was: cvs)

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

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

[JIRA] (JENKINS-11356) Tycho projects - support cvs parent projects and read manifest-dependencies

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke updated JENKINS-11356:
-

Component/s: (was: cvs)

This isn't a CVS specific issue (it affects SVN and other module based 
repositories too). It would probably be best fixed by creating a new plugin 
(like the suggestions of creating a plugin to read eclipse projectsets rather 
than try and update the CVS, SVN and GIT plugins with identical functionality)

> Tycho projects - support cvs parent projects and read manifest-dependencies
> ---
>
> Key: JENKINS-11356
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11356
> Project: Jenkins
>  Issue Type: New Feature
>  Components: maven2
> Environment: Ubuntu Linux 32-bit 11.04, Maven 3, Tycho 0.12.0, 
> Jenkins 1.434
>Reporter: Thomas Kuchel
>Assignee: olamy
> Attachments: Bildschirmfoto-2.png
>
>
> Hello all :)
> I want to build eclipse tycho projects with Jenkins. 
> Therefore I used the "minerva" git-based test project (docs: 
> http://wiki.eclipse.org/Minerva; download: 
> https://github.com/caniszczyk/minerva) and split it into several cvs projects 
> (because we still use cvs). The containing eclipse bundles and features were 
> build with the help of a parent pom (the're defined as submodules), which i 
> packed into a separate project. When I add all the cvs projects to Jenkins 
> and start building, I get 2 problems:
> 1. The submodules won't be found (because of the "../submodule-name" - path 
> link) and
> 2. If I build the submodules without jenkins and install them to my local 
> repository, they will be found when building the parent with jenkins. But if 
> there's a dependency defined within the manifest.mf of a submodule, which 
> refers to another submodule, jenkins can't resolve this because it doesn't 
> read this file in every tycho-project.
> The file/dependency structure (abstract) is attached.
> I know that this is a special problem, because everyone builds tycho projects 
> out of a git repository and so it's only one project and everything is built 
> at once. Therefore there is no need to read the manifest-dependencies and 
> create the correct build order.
> Thank you for your help.
> Regards, Thomas

--
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-12632) Subversion plugin update fails

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke resolved JENKINS-12632.
--

  Assignee: Michael Clarke
Resolution: Fixed

Last comment indicates this was fixed under another defect. Please reopen and 
provide details if you believe this is not the case.

> Subversion plugin update fails
> --
>
> Key: JENKINS-12632
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12632
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs, plugin, subversion, update-center
> Environment: Jenkins 1.450
> CentOS 6.2 (2.6.32-220.4.1.el6.centos.plus.x86_64)
> java version "1.6.0_29"
> Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
>Reporter: Paul Milliken
>Assignee: Michael Clarke
>  Labels: jenkins, plugin
>
> I'm encountering an issue similar to JENKINS-12514 with Jenkins 1.450.
> Update manager reports that I'm running subversion plugin 1.34 and 1.37 is 
> available. In my plugins folder I can see:
> -rw-rw-r--. 1 jenkins jenkins  2105983 Feb  2 15:20 subversion.bak
> -rw-rw-r--. 1 jenkins jenkins  2105983 Feb  2 15:20 subversion.jpi
> I tell Jenkins to install 1.37. Once it's downloaded I can see:
> -rw-rw-r--. 1 jenkins jenkins  2105983 Feb  2 15:20 subversion.bak
> -rw-rw-r--. 1 jenkins jenkins  2103308 Feb  2 15:43 subversion.jpi
> Checking the manifests:
> [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep 
> Plugin-Version
> Plugin-Version: 1.34
> [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep 
> Plugin-Version
> Plugin-Version: 1.37
> Restart jenkins to apply the changes. At this point, the present files are:
> -rw-rw-r--. 1 jenkins jenkins  2105983 Feb  2 15:20 subversion.bak
> -rw-rw-r--. 1 jenkins jenkins  2105983 Feb  2 15:20 subversion.jpi
> and the manifests:
> [jenkins@ plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep 
> Plugin-Version
> Plugin-Version: 1.34
> [jenkins@ plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep 
> Plugin-Version
> Plugin-Version: 1.34
> And update manager still reports 1.34 with 1.37 available.

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

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

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke updated JENKINS-12582:
-

Priority: Major  (was: Blocker)

Lowering priority as there is a workaround to this. There are plans to allow a 
global setting of passwords for a Jenkins instance but we need to clear 
functional issues first

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

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

[JIRA] (JENKINS-12598) In 2.0 update you need to specify branch for every module

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-12598:


Code changed in jenkins
User: mc1arke
Path:
 src/main/java/hudson/scm/CvsRepository.java
http://jenkins-ci.org/commit/cvs-plugin/1db398a3e0462b188065063446723622eb8b04a1
Log:
  [FIXED JENKINS-12598] migrate settings between plugin versions






> In 2.0 update you need to specify branch for every module
> -
>
> Key: JENKINS-12598
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12598
> Project: Jenkins
>  Issue Type: Improvement
>  Components: cvs
>Reporter: Ulli Hafner
>Assignee: Michael Clarke
>Priority: Critical
> Attachments: Jenkins_CvsPluginModules.png, 
> repositoryLocationProposal.png
>
>
> After an upgrade to the new 2.0 version of the cvs plug-in we now need to 
> specify the "Module location" (trunk, branch) for each module. This is quite 
> cumbersome if you have a lot of modules. In the 1.x plug-in releases you are 
> able to select a given branch for all modules in one text field.
> While I think the new "feature" has a lot of use cases (i.e., having trunk 
> and branches mixed), the usability could be improved here. My requirement is 
> to select/change the branch (or trunk) for all modules in a simple way.
> A non-Ajax suggestion would be to have a "default" entry in the Selection, 
> i.e. Trunk, Branch, Tag, Default. And you can define the default behavior at 
> the top of the cvs configuration. 

--
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-12598) In 2.0 update you need to specify branch for every module

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon resolved JENKINS-12598.


Resolution: Fixed

> In 2.0 update you need to specify branch for every module
> -
>
> Key: JENKINS-12598
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12598
> Project: Jenkins
>  Issue Type: Improvement
>  Components: cvs
>Reporter: Ulli Hafner
>Assignee: Michael Clarke
>Priority: Critical
> Attachments: Jenkins_CvsPluginModules.png, 
> repositoryLocationProposal.png
>
>
> After an upgrade to the new 2.0 version of the cvs plug-in we now need to 
> specify the "Module location" (trunk, branch) for each module. This is quite 
> cumbersome if you have a lot of modules. In the 1.x plug-in releases you are 
> able to select a given branch for all modules in one text field.
> While I think the new "feature" has a lot of use cases (i.e., having trunk 
> and branches mixed), the usability could be improved here. My requirement is 
> to select/change the branch (or trunk) for all modules in a simple way.
> A non-Ajax suggestion would be to have a "default" entry in the Selection, 
> i.e. Trunk, Branch, Tag, Default. And you can define the default behavior at 
> the top of the cvs configuration. 

--
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-13975) Promoted-builds not following jenkins access control policies

[bruce.e...@gmail.com (JIRA)]

Bruce Edge created JENKINS-13975:


 Summary: Promoted-builds not following jenkins access control 
policies
 Key: JENKINS-13975
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13975
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Affects Versions: current
 Environment: Jenkins head release with updated plugins on Ubuntu 11.10
Reporter: Bruce Edge
Priority: Minor


If the jenkins master config setting is set to "Logged in users can do 
anything", I would expect that to apply to build promotions as well.
Instead, if there's no user restriction on the build promotion setting, 
non-logged-in users can still promote builds.

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

[JIRA] (JENKINS-13974) Promoted-builds groups not picking up user groups

[bruce.e...@gmail.com (JIRA)]

Bruce Edge created JENKINS-13974:


 Summary: Promoted-builds groups not picking up user groups
 Key: JENKINS-13974
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13974
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Affects Versions: current
 Environment: Current head of jenkins with fully updated plugins.
Reporter: Bruce Edge


I can specify a list of users that are allowed to promote builds, but I can't 
use linux user groups to specify who can promote builds.
The docs imply that groups can be used, but this does not appear to be the case.

Note that my groups are pulled from ldap.

$> id
uid=1061(bedge) gid=1000(builduser) groups=1000(builduser)

Specifying "builduser" does not show the "approve" button.

Specifying "bedge" does work, but builduser does not.

--
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-13716) Default graph configuration for project is not read

[ullrich.haf...@gmail.com (JIRA)]

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

Ulli Hafner commented on JENKINS-13716:
---

Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins 
Analysis Plug-ins (Compile) 
#523|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/523/]
 [JENKINS-13716] Fixed file name of default graph configuration. (Revision 
b8cc4bfda98847b446d647b5e34ec6cea7df5d3a)

 Result = SUCCESS

> Default graph configuration for project is not read
> ---
>
> Key: JENKINS-13716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13716
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: Ulli Hafner
>Assignee: Ulli Hafner
>Priority: Minor
>
> Seems that the defaults for the trend graph that are read from a file don not 
> work anymore.

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

[jgustaf...@ecrio.com (JIRA)]

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

James Gustafson commented on JENKINS-13227:
---

Using the latest 2.4 snapshot from May 31, Jenkins is now able to detect 
changes for me, and it fixed the "No file version found for the specified tag" 
issue that I started seeing as well. I am back to making regular builds, thanks 
for the fixes!

> 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-13973) java.lang.AssertionError: null is missing its descriptor in public hudson.util.CopyOnWriteList hudson.plugins.warnings.WarningsDescriptor.getParsers()

[li...@exroot.org (JIRA)]

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

Tomasz Melcer closed JENKINS-13973.
---

Resolution: Fixed

>From IRC:
{noformat}
21:43 <+drulli> liori: I already fixed that
21:43 <+drulli> I think I make a new release next week
{noformat}

> java.lang.AssertionError: null is missing its descriptor in public 
> hudson.util.CopyOnWriteList 
> hudson.plugins.warnings.WarningsDescriptor.getParsers()
> --
>
> Key: JENKINS-13973
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13973
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Affects Versions: current
> Environment: Jenkins 1.447 installed from Debian testing package, 
> Warnings plugin version 4.5.
>Reporter: Tomasz Melcer
>Assignee: Ulli Hafner
>Priority: Critical
> Attachments: warnings.txt
>
>
> {noformat}
> WARNING: Caught exception evaluating: 
> descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: 
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
> [...]
>   at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.AssertionError: null is missing its descriptor in public 
> hudson.util.CopyOnWriteList 
> hudson.plugins.warnings.WarningsDescriptor.getParsers(). See 
> https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor
>   at 
> hudson.model.Descriptor$PropertyType.getItemTypeDescriptorOrDie(Descriptor.java:194)
>   ... 143 more
> {noformat}
> when going to http://JENKINS_URL/configure. This blocks the whole configure 
> page, making it unusable. Full traceback 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-13973) java.lang.AssertionError: null is missing its descriptor in public hudson.util.CopyOnWriteList hudson.plugins.warnings.WarningsDescriptor.getParsers()

[li...@exroot.org (JIRA)]

Tomasz Melcer created JENKINS-13973:
---

 Summary: java.lang.AssertionError: null is missing its descriptor 
in public hudson.util.CopyOnWriteList 
hudson.plugins.warnings.WarningsDescriptor.getParsers()
 Key: JENKINS-13973
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13973
 Project: Jenkins
  Issue Type: Bug
  Components: warnings
Affects Versions: current
 Environment: Jenkins 1.447 installed from Debian testing package, 
Warnings plugin version 4.5.
Reporter: Tomasz Melcer
Assignee: Ulli Hafner
Priority: Critical
 Attachments: warnings.txt

{noformat}
WARNING: Caught exception evaluating: 
descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: 
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
[...]

at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.AssertionError: null is missing its descriptor in public 
hudson.util.CopyOnWriteList 
hudson.plugins.warnings.WarningsDescriptor.getParsers(). See 
https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor
at 
hudson.model.Descriptor$PropertyType.getItemTypeDescriptorOrDie(Descriptor.java:194)
... 143 more
{noformat}

when going to http://JENKINS_URL/configure. This blocks the whole configure 
page, making it unusable. Full traceback 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-13953) can't Deploy artifacts to Artifactory

[jasonrhic...@gmail.com (JIRA)]

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

Jason Hickey commented on JENKINS-13953:


https://issues.jfrog.org/jira/browse/HAP-316
Looks like this may be addressed in the latest update 2.1.1 


> can't Deploy artifacts to Artifactory
> -
>
> Key: JENKINS-13953
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13953
> Project: Jenkins
>  Issue Type: Bug
>  Components: artifactdeployer
>Affects Versions: current
>Reporter: maritzabell suarez
>  Labels: plugin
> Attachments: ArtifactoryConfigurationOnJenkins.jpg, 
> ArtifactoryConfigurationOnJenkinsTask.jpg
>
>
> hi!
> i'm trying to deploy artifacts to artifactory and i followed the tutorial, 
> however, i got the same problem no matter what:
> Waiting for Jenkins to finish collecting data
> channel stopped
> Deploying artifacts to http://192.168.1.22/artifactory
> Deploying artifacts of module: 
> etask.components.security:COM-SecurityGuardEntities
> ERROR: null
> java.lang.NullPointerException
>   at 
> org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106)
>   at 
> org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170)
>   at 
> org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127)
>   at 
> org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685)
>   at 
> hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632)
>   at hudson.model.Run.run(Run.java:1463)
>   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:239)
> Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE
> Finished: FAILURE
> it doesn't say anything i can use to resolve the problem.
> i attached the configuration of jenkins
> thank you so much for the help,
> Maritzabell Suarez

--
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-13970) Build variable CC_BASELINE not populated with used baseline

[tim.pillsb...@gmail.com (JIRA)]

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

Tim Pillsbury updated JENKINS-13970:


Description: 
CCUCM says it is using the latest baseline, but the CC_BASELINE build variable 
is not always set to it.
The problem seems to occur after "Updating view using all modules" if CCUCM 
finds activities and versions involved.
{panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
[CCUCM] Retrieved 28 baselines:
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT 
2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT 
2012)
[CCUCM]   ...
[CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT 
2012)*_(n)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT 
2012)
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)

[CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
[CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except 
CPF\workspace\view
[CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Reusing view root
[CCUCM] Determine if view tag exists
[CCUCM] Reusing view tag
[CCUCM] UUID resulted in CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Getting snapshotview
[CCUCM] Rebasing development stream 
(CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent stream 
(WRKB_RLS_2012_06_00_ECM) Done
[CCUCM] Updating view using all modules
[CCUCM] _*Found 3 activities. 20 versions involved*_(i)
{panel}

But then Injected environment variable CC_BASELINE is incorrect

{panel:title=Injected environment 
variables|titleBGColor=#E7D6C1|bgColor=#CE}
|CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
{panel}

  was:
CCUCM says it is using the latest baseline, but the CC_BASELINE build variable 
is not always set to it.
The problem seems to occur after "Updating view using all modules" if CCUCM 
finds activities and versions involved.
{panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
[CCUCM] Retrieved 28 baselines:
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT 
2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT 
2012)
[CCUCM]   ...
[CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT 
2012)*_(n)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT 
2012)
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)

[CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
[CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except 
CPF\workspace\view
[CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Reusing view root
[CCUCM] Determine if view tag exists
[CCUCM] Reusing view tag
[CCUCM] UUID resulted in CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Getting snapshotview
[CCUCM] Rebasing development stream 
(CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent stream 
(WRKB_RLS_2012_06_00_ECM) Done
[CCUCM] Updating view using all modules
[CCUCM] Found 3 activities. 20 versions involved
{panel}

But then Injected environment variable CC_BASELINE is incorrect

{panel:title=Injected environment 
variables|titleBGColor=#E7D6C1|bgColor=#CE}
|CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
{panel}


> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
>  Issue Type: Bug
>  Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition, 
> Service Pack 2
>Reporter: Tim Pillsbury
>  Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build 
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM 
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT 
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT 
> 2012)
> [CCUCM]   ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT 
> 2012)*_(n)
> [CCUCM] + WRKB_

[JIRA] (JENKINS-13972) Concurrent matrix builds abort

[jkoles...@google.com (JIRA)]

John Koleszar created JENKINS-13972:
---

 Summary: Concurrent matrix builds abort
 Key: JENKINS-13972
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13972
 Project: Jenkins
  Issue Type: Bug
  Components: concurrent-build
Affects Versions: current
Reporter: John Koleszar
Assignee: Kohsuke Kawaguchi
Priority: Minor


Reproduction case:

Create a concurrent matrix job with a user defined axis that does a 'sleep 120' 
as its build step. Launch several of these jobs, enough that all available 
executors are taken up and there are still builds in the queue. Some of these 
builds will abort, with a console message similar to:

[...]
9 completed with result SUCCESS
24 completed with result SUCCESS
23 completed with result SUCCESS
2 completed with result SUCCESS
10 appears to be cancelled
10 completed with result ABORTED
25 appears to be cancelled
25 completed with result ABORTED
18 appears to be cancelled
18 completed with result ABORTED
13 appears to be cancelled
[...]

For my test case, I have 26 slaves, 82 executors, 25 sub-jobs. I can reproduce 
reliably if I launch 5 or more top level jobs at once.




--
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-13971) Added possibility to use "JIRA Release Version parameter" from a triggered build

[ch...@lovsund.se (JIRA)]

Christian Lövsund created JENKINS-13971:
---

 Summary: Added possibility to use "JIRA Release Version parameter" 
from a triggered build
 Key: JENKINS-13971
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13971
 Project: Jenkins
  Issue Type: Patch
  Components: jira
Affects Versions: current
Reporter: Christian Lövsund
 Attachments: vcs-diff6952185659888379490.patch

By overriding getDefaultParameterValue() in the JiraVersionParameterDefinition 
class.


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

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon resolved JENKINS-13227.


Resolution: Fixed

> 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

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-13227:


Code changed in jenkins
User: mc1arke
Path:
 src/main/java/hudson/scm/CvsChangeLogHelper.java
http://jenkins-ci.org/commit/cvs-plugin/cd691b3c0d97c04249a5f60db2d7a961f2d680eb
Log:
  [FIXED JENKINS-13227] skip files not in current tag rather than throw 
exception






> 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

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13227:
--

I know why the exception is thrown and can resolve that. I don't understand the 
different timestamps but can take a guess (someone with more knowledge of 
matrix builds will have to confirm my ideas).

The CVS plugin does all commands with timestamps from the last completed 
(non-cancelled) job. Since matrix builds are really a set of different builds 
grouped under one run, different matrix configuration (I think it refers to 
them as axis) could potentially give different timestamps for a completed run. 
Can you look at your jobs and let me know if you can see any timestamps 
differing for last run start time (or end time) so I can either exclude this as 
an issue or try and investigate further.

I'll fix the exception in the meantime (some files could be changed in CVS and 
not be on the branch/tag we're looking at, when we set a filter on RLOG to only 
bring back a specific branch this was valid, but the assumption is now 
incorrect and likely to be broken).

> 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-13827) Getting OutOfMemoryError after Jenkins has been running for several days

[ed.pala...@kofax.com (JIRA)]

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

Ed Palazzo commented on JENKINS-13827:
--

We continue to have this problem with OutOfMemory Exceptions. It happened again 
last night, which is about right... every one to two weeks.

Has anyone had a chance to look at the heap dump?

Thanks in advance.

-ed-

> Getting OutOfMemoryError after Jenkins has been running for several days
> 
>
> Key: JENKINS-13827
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13827
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
> Environment: Jenkins 1.458
> Red Hat Enterprise Linux ES release 4 (Nahant Update 4) 
> 32-bit hardware and OS
> java 1.6.0_17
> perforce plugin 1.3.8
> 8 virtual CPUs
> 16 GB total available memory on the system
>Reporter: Ed Palazzo
>
> After running from anywhere from one to two weeks, Jenkins will appear to be 
> frozen. Examination of the logs shows the following error:
>  java.lang.OutOfMemoryError: GC overhead limit exceeded
> I've done numerous stack dumps, and it is fairly inconsistent as to what is 
> happening when the error occurs. This last time I did a heap dump per the 
> instructions on this page: 
> https://wiki.jenkins-ci.org/display/JENKINS/I%27m+getting+OutOfMemoryError
> The heap is available for download via FTP here:  
> ftp://Jenkins:maqla...@kpsg.kofax.com/heap.bin.gz
> It's about 300M compressed (~1.6GB uncompressed). I had a hard time running 
> jhat against the heap -- maybe you'll have more luck.
> I should let you know that I have 565 jobs (all modules of different 
> branches) configured on this system. I have one slave running builds, with 
> another two machines on the way.
> Let me know what else I can provide to help debug.

--
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-13175) Testlink Job Configuration using dropdownlist instead static box

[brunodepau...@yahoo.com.br (JIRA)]

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

Work on JENKINS-13175 started by Bruno P. Kinoshita.

> Testlink Job Configuration using dropdownlist instead static box
> 
>
> Key: JENKINS-13175
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13175
> Project: Jenkins
>  Issue Type: Improvement
>  Components: testlink
>Affects Versions: current
> Environment: Centos
>Reporter: Victor Martinez
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: plugin
> Attachments: Testlink_Plugin_Configuration.PNG, 
> Testlink_TestProjects.PNG
>
>
> Instead to have a static box for filling the Testlink Job Configuration, it 
> would be quite useful if you could implement the dropdownlist for each field 
> configuration:
>   Testlink Version
>   Test Project Name
>   Test Plan Name
>   
>   Then choosing the Testlink version the field "test project name" will show 
> the list of projects for that testlink version, and once you have chosen it 
> the field testplan name will show the list of test plans for that test 
> project.
>   Please find attached a couple of snapshot (only TestLink Version and Test 
> Project Name)
> Regards

--
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-13629) When creating a new build in TestLink, plugin should automatically assign test case execution to a user

[brunodepau...@yahoo.com.br (JIRA)]

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

Bruno P. Kinoshita commented on JENKINS-13629:
--

Hi Robert, I will add the required code in TestLink XMl-RPC/TestLink Java 
API/Jenkins Plug-in, but first would like your feedback on some items:

- We will assign the test to the user that jenkins is using (it is the user 
whom owns the devKey that Jenkins is configured to use)
- Should we assign the test execution a) before test execution or b) after test 
execution (in case the build failed, and we chose a), the tests would have been 
assigned but not executed).
- By default, we keep the same behaviour as now. There will be a new field for 
setting the assigned user name (later I will add a method to list the users, 
after thinking if it wouldn't be a security issue)

Thanks!

> When creating a new build in TestLink, plugin should automatically assign 
> test case execution to a user
> ---
>
> Key: JENKINS-13629
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13629
> Project: Jenkins
>  Issue Type: Improvement
>  Components: testlink
>Affects Versions: current
>Reporter: Robert Campbell
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: jenkins, plugins, testlink
>
> TestLink only reports some statistics correctly when executed test cases have 
> been assigned to a user. Although it is possible to change the assignment 
> manually post-execution it would be better if the TestLink plugin did this 
> automatically when creating a new build e.g. assign all test cases (to be) 
> executed by Jenkins to a jenkins-ci TestLink user.
> This may also require changes to the TestLink API.

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

[ah...@hotmail.com (JIRA)]

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

Amir Isfy edited comment on JENKINS-13227 at 5/31/12 5:09 PM:
--

Sounds like a plan.

Michael, I am getting this with this new snapshot. It is during the 'rlog' 
command.

First member of my matrix checks out and builds fine. Its rlog command is:

08:20:30  cvs rlog -S -d30 May 2012 17:13:58 -0600<31 May 2012 08:13:55 -0600 
Module_name

The second member of the matrix, checking out the same exact code, rlog command 
is:

08:57:51  cvs rlog -S -d17 May 2012 09:30:15 -0600<31 May 2012 08:13:55 -0600 
Module_name

Note the times! The second command fails with: 


17:25:04  FATAL: No file version found for the specified tag. Looking for 
branch_name in 
17:25:04  java.lang.RuntimeException: No file version found for the specified 
tag. Looking for branch_name in 
17:25:04at 
hudson.scm.CvsChangeLogHelper.getCurrentFileVersion(CvsChangeLogHelper.java:273)
17:25:04at 
hudson.scm.CvsChangeLogHelper.mapCvsLog(CvsChangeLogHelper.java:151)
17:25:04at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:419)
17:25:04at hudson.scm.CVSSCM.checkout(CVSSCM.java:831)
17:25:04at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
17:25:04at hudson.model.Run.run(Run.java:1434)
17:25:04at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
17:25:04at 
hudson.model.ResourceController.execute(ResourceController.java:88)
17:25:04at hudson.model.Executor.run(Executor.java:239)

This is after the very last rlog message on the console output!!

On other slaves, I have this happening on the first member of the matrix or 
even on the master before triggering the first member of the matrix.

Sometimes when I clean the workspace and relaunch, it goes one step further, 
for example if it had failed on the master, now it passes and fails at the 
first member of the matrix on the slave!

  was (Author: amofpers):
Sounds like a plan.

Michael, I am getting this with this new snapshot. It is during the 'rlog' 
command.

First member of my matrix checks out and builds fine. Its rlog command is:

08:20:30  cvs rlog -S -d30 May 2012 17:13:58 -0600<31 May 2012 08:13:55 -0600 
Module_name

The second member of the matrix, checking out the same exact code, rlog command 
is:

08:57:51  cvs rlog -S -d17 May 2012 09:30:15 -0600<31 May 2012 08:13:55 -0600 
Module_name

Note the times! The second command fails with: 


17:25:04  FATAL: No file version found for the specified tag. Looking for 
branch_name in 
17:25:04  java.lang.RuntimeException: No file version found for the specified 
tag. Looking for branch_name in 
17:25:04at 
hudson.scm.CvsChangeLogHelper.getCurrentFileVersion(CvsChangeLogHelper.java:273)
17:25:04at 
hudson.scm.CvsChangeLogHelper.mapCvsLog(CvsChangeLogHelper.java:151)
17:25:04at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:419)
17:25:04at hudson.scm.CVSSCM.checkout(CVSSCM.java:831)
17:25:04at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
17:25:04at hudson.model.Run.run(Run.java:1434)
17:25:04at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
17:25:04at 
hudson.model.ResourceController.execute(ResourceController.java:88)
17:25:04at hudson.model.Executor.run(Executor.java:239)

On other slaves, I have this happening on the first member of the matrix or 
even on the master before triggering the first member of the matrix.

Sometimes when I clean the workspace and relaunch, it goes one step further, 
for example if it had failed on the master, now it passes and fails at the 
first member of the matrix on the slave!
  
> 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) 
> 

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

[ah...@hotmail.com (JIRA)]

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

Amir Isfy commented on JENKINS-13227:
-

Sounds like a plan.

Michael, I am getting this with this new snapshot. It is during the 'rlog' 
command.

First member of my matrix checks out and builds fine. Its rlog command is:

08:20:30  cvs rlog -S -d30 May 2012 17:13:58 -0600<31 May 2012 08:13:55 -0600 
Module_name

The second member of the matrix, checking out the same exact code, rlog command 
is:

08:57:51  cvs rlog -S -d17 May 2012 09:30:15 -0600<31 May 2012 08:13:55 -0600 
Module_name

Note the times! The second command fails with: 


17:25:04  FATAL: No file version found for the specified tag. Looking for 
branch_name in 
17:25:04  java.lang.RuntimeException: No file version found for the specified 
tag. Looking for branch_name in 
17:25:04at 
hudson.scm.CvsChangeLogHelper.getCurrentFileVersion(CvsChangeLogHelper.java:273)
17:25:04at 
hudson.scm.CvsChangeLogHelper.mapCvsLog(CvsChangeLogHelper.java:151)
17:25:04at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:419)
17:25:04at hudson.scm.CVSSCM.checkout(CVSSCM.java:831)
17:25:04at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
17:25:04at 
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
17:25:04at hudson.model.Run.run(Run.java:1434)
17:25:04at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
17:25:04at 
hudson.model.ResourceController.execute(ResourceController.java:88)
17:25:04at hudson.model.Executor.run(Executor.java:239)

On other slaves, I have this happening on the first member of the matrix or 
even on the master before triggering the first member of the matrix.

Sometimes when I clean the workspace and relaunch, it goes one step further, 
for example if it had failed on the master, now it passes and fails at the 
first member of the matrix on the slave!

> 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-13970) Build variable CC_BASELINE not populated with used baseline

[tim.pillsb...@gmail.com (JIRA)]

Tim Pillsbury created JENKINS-13970:
---

 Summary: Build variable CC_BASELINE not populated with used 
baseline
 Key: JENKINS-13970
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
 Project: Jenkins
  Issue Type: Bug
  Components: clearcase-ucm
Affects Versions: current
 Environment: Microsoft Windows Server 2003, Standard x64 Edition, 
Service Pack 2
Reporter: Tim Pillsbury


CCUCM says it is using the latest baseline, but the CC_BASELINE build variable 
is not always set to it.
The problem seems to occur after "Updating view using all modules" if CCUCM 
finds activities and versions involved.
{panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
[CCUCM] Retrieved 28 baselines:
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT 
2012)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT 
2012)
[CCUCM]   ...
[CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT 
2012)*_(n)
[CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT 
2012)
[CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)

[CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
[CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except 
CPF\workspace\view
[CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Reusing view root
[CCUCM] Determine if view tag exists
[CCUCM] Reusing view tag
[CCUCM] UUID resulted in CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
[CCUCM] Getting snapshotview
[CCUCM] Rebasing development stream 
(CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent stream 
(WRKB_RLS_2012_06_00_ECM) Done
[CCUCM] Updating view using all modules
[CCUCM] Found 3 activities. 20 versions involved
{panel}

But then Injected environment variable CC_BASELINE is incorrect

{panel:title=Injected environment 
variables|titleBGColor=#E7D6C1|bgColor=#CE}
|CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
{panel}

--
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-13969) Warnings Plugin does not recognize Eclipse Java warnings

[alexander.weickm...@faktorzehn.de (JIRA)]

Alexander Weickmann created JENKINS-13969:
-

 Summary: Warnings Plugin does not recognize Eclipse Java warnings
 Key: JENKINS-13969
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13969
 Project: Jenkins
  Issue Type: Bug
  Components: warnings
Reporter: Alexander Weickmann
Assignee: Ulli Hafner


The following warnings are not detected by Jenkins, even tough they are written 
to console:

{noformat}
[INFO] Compiling 5 source files to 
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/target/classes
[WARNING] 
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[369,0]
 
private boolean compare(List rowTableValues, List 
allowedValues) {


The method compare(List, List) from the type PmModelImporter is 
never used locally
[WARNING] 
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[391,0]
 
private List getTableValues(PropertyRestrictionType 
restrictionType) {
 
^^^
The method getTableValues(PropertyRestrictionType) from the type 
PmModelImporter is never used locally
2 problems (2 warnings)
{noformat}

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

[JIRA] (JENKINS-13934) Make it possible to delete all except latest 'n' archived artifacts

[paul.cro...@softwareag.com (JIRA)]

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

Paul Croome commented on JENKINS-13934:
---

Many thanks for the information. Perhaps the text "Max # of builds to keep with 
artifacts" is a bit misleading? I tend to think of builds and artifacts as 
being separate (though related) entities, so "builds with artifacts" confused 
me. Anyway, thanks to your help, I now know how to achieve what I wanted.

> Make it possible to delete all except latest 'n' archived artifacts
> ---
>
> Key: JENKINS-13934
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13934
> Project: Jenkins
>  Issue Type: Improvement
>  Components: postbuild-task
>Affects Versions: current
> Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466
>Reporter: Paul Croome
>Assignee: OHTAKE Tomohiro
>Priority: Minor
> Attachments: Max_number_of_builds_to_keep_with_artifacts.png
>
>
> In the job configuration page, under Post-build Actions > Archive the 
> Artifacts > Advanced
> it's possible to select the checkbox "Discard all but the last 
> successful/stable artifact to save disk space".
> It would be useful if I could choose "Discard all but the last 'n' 
> successful/stable artifacts to save disk space".
> (By comparison: The option "Discard Old Builds" allows me to specify "Max # 
> of builds to keep". A similar feature for archived artifacts would be nice.)

--
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-11964) [Regression] Cannot build a single module in a Maven multi-module job with Maven 3

[s...@red-illusions.dk (JIRA)]

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

Sune Wettersteen commented on JENKINS-11964:


Is anyone actively looking into this?
It is one of the stumbling blocks for us in order to upgrade to maven 3.

Any feedback is appreciated.

> [Regression] Cannot build a single module in a Maven multi-module job with 
> Maven 3
> --
>
> Key: JENKINS-11964
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11964
> Project: Jenkins
>  Issue Type: Bug
>  Components: maven
>Reporter: henryju
>Assignee: olamy
>
> We have upgraded from Jenkins 1.399 to Jenkins 1.441. Our Maven jobs are now 
> run by Maven 3.0.3 instead of Maven 2.2.1.
> When a job is a Maven multi-module project, it is possible to run a single 
> submodule (on the job page, click on "Modules", then start the build for a 
> given submodule). It was working fine with our old instance but now the build 
> fails with status "ABORTED".
> See thread: 
> http://jenkins.361315.n4.nabble.com/Build-Maven-submodule-gt-ABORTED-td4128116.html
> Is it possible to reintroduce this feature?
> 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-13968) Dashboard plugin: request for failing jobs portlet

[sdrot...@gmail.com (JIRA)]

Steve Roth created JENKINS-13968:


 Summary: Dashboard plugin: request for failing jobs portlet
 Key: JENKINS-13968
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13968
 Project: Jenkins
  Issue Type: Improvement
  Components: dashboard-view
Reporter: Steve Roth
Assignee: Peter Hayes
Priority: Minor


The dashboard-view plugin is really nice.

One thing which would be helpful for our team is have a portlet very similar to 
the 'unstable jobs' portlet, which shows only failing jobs (red ball jobs).   
This is high priority information, and it's useful to show it in the dashboard.

--
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-10787) Dashboard view does not display Dropdownviews taskbar

[sdrot...@gmail.com (JIRA)]

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

Steve Roth resolved JENKINS-10787.
--

Resolution: Cannot Reproduce

This is no longer an issue with Jenkins 1.454

> Dashboard view does not display Dropdownviews taskbar
> -
>
> Key: JENKINS-10787
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10787
> Project: Jenkins
>  Issue Type: Bug
>  Components: dashboard-view
>Affects Versions: current
>Reporter: Steve Roth
>Assignee: Peter Hayes
>Priority: Minor
>
> When the DropDownViews taskbar is enabled and selected, the dashboard view 
> does not display using it -- it uses the standard tab approach.  
> This causes issues in some cases such as when lots of sub-views are 
> configured, since the width of the page is huge, and therefore the dashboard 
> portlets are also huge, and require scrolling to see all of the columns.
> Occurs in Jenkins 1.424

--
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-10787) Dashboard view does not display Dropdownviews taskbar

[sdrot...@gmail.com (JIRA)]

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

Steve Roth commented on JENKINS-10787:
--

This is no longer an issue in Jenkins 1.454 -- thanks for the fix!

> Dashboard view does not display Dropdownviews taskbar
> -
>
> Key: JENKINS-10787
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10787
> Project: Jenkins
>  Issue Type: Bug
>  Components: dashboard-view
>Affects Versions: current
>Reporter: Steve Roth
>Assignee: Peter Hayes
>Priority: Minor
>
> When the DropDownViews taskbar is enabled and selected, the dashboard view 
> does not display using it -- it uses the standard tab approach.  
> This causes issues in some cases such as when lots of sub-views are 
> configured, since the width of the page is huge, and therefore the dashboard 
> portlets are also huge, and require scrolling to see all of the columns.
> Occurs in Jenkins 1.424

--
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-13967) Xunit don't recognize cppunit report with time execution

[nicolas.ja...@gmail.com (JIRA)]

Nicolas JAN created JENKINS-13967:
-

 Summary: Xunit don't recognize cppunit report with time execution
 Key: JENKINS-13967
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13967
 Project: Jenkins
  Issue Type: Bug
  Components: xunit
Affects Versions: current
 Environment: Ubuntu Desktop 12.04 64 bits with Jenkins 1.466 with 
tomcat7 (from ubuntu package)
cppunit -1.12.1-4 (from ubuntu package)
Reporter: Nicolas JAN
Assignee: Gregory Boissinot
 Attachments: cppunit-report.xml

Hi,

Since I have added the clocker plugin to my cppunit code(It is a cppunit plugin 
which permit to have the time execution, available into the samples of the 
cppunit archive), xunit don't reconize the format of the cppunit report.

In fact, jenkins says that :
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing CppUnit-1.12.1 (default)
[xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found 
with the pattern 'report/cppunit-report.xml' relative to 
'/home/nicolas/jenkins/workspace/ProjectA' for the testing framework 
'CppUnit-1.12.1 (default)'.

[xUnit] [ERROR] - The result file 
'/home/nicolas/jenkins/workspace/ProjectA/report/cppunit-report.xml' for the 
metric 'CppUnit' is not valid. The result file has been skipped.
[xUnit] [INFO] - Setting the build status to FAILURE
[xUnit] [INFO] - Stopping recording.
Build step 'Publish xUnit test result report' changed build result to 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-13965) LDAP trouble : gets the info, but error 32 still

[simon.gare...@scilab.org (JIRA)]

simon gareste created JENKINS-13965:
---

 Summary: LDAP trouble : gets the info, but error 32 still
 Key: JENKINS-13965
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13965
 Project: Jenkins
  Issue Type: Bug
  Components: ldapemail
Affects Versions: current
 Environment: debian wheezy
Reporter: simon gareste
Assignee: justinedelson


Jenkins version 1.466, run as java -jar jenkins.war, using apache 2.2.22 as web 
server

after configuring my ldap : 
  
ldap://our.server.com
OU=people,DC=company,DC=com
false

mail={0}
OU=people,DC=company,DC=com
CN=manager,DC=company,DC=com
X3NjaWxhYl8=
  

We try to login, and always get the error 32

May 31, 2012 4:59:38 PM hudson.security.AuthenticationProcessingFilter2 
onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: LdapCallback;[LDAP: error 
code 32 - No Such Object]; nested exception is 
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; 
remaining name 'mail=si...@company.com'; nested exception is 
org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP: error code 
32 - No Such Object]; nested exception is javax.naming.NameNotFoundException: 
[LDAP: error code 32 - No Such Object]; remaining name 'mail=si...@company.com'
at 
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:238)
at 
org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
at 
org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
at 
org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45)
at 
org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71)
at 
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at 
hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
at 
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at 
hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at 
hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
at 
winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP: 
error code 32 - No Such Object]; nested exception is 
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; 
remaining name 'mail=si...@company.com'
at 
org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at 
org.acegisecurity.ldap.LdapTemplate.retrieveEntry(LdapTemplate.java:165)
at 
org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.bindWithDn(BindAuthenticator.java:87)
at 
org.acegisecurity.providers.ldap.authenticator.B

[JIRA] (JENKINS-13966) Parameter Factories on Trigger parameterized build

[dav...@hmgcc.gov.uk (JIRA)]

david e created JENKINS-13966:
-

 Summary: Parameter Factories on Trigger parameterized build
 Key: JENKINS-13966
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13966
 Project: Jenkins
  Issue Type: New Feature
  Components: nodelabelparameter, parameterized-trigger
 Environment: Windows Server 2008 R2
Jenkins v1.450
parameterized-trigger v2.12
nodelabelparameter v1.1.4
Reporter: david e
Assignee: domi
Priority: Minor


When configuring a build trigger build step one can specify a parameter 
factory, like the very useful "All Nodes for Label Factory" from Node and Label 
parameter plugin.

It would be useful to have the same parameter factory options when configuring 
a trigger parameterized build post-build step.

--
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-13820) please create possibility to automatically set order of execution of matrix subtasks based on previously tracked time

[lvoty...@redhat.com (JIRA)]

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

Lucie Votypkova resolved JENKINS-13820.
---

Resolution: Fixed

I did new release so it should be available after next restart of Jenkins

> please create possibility to automatically set order of execution of matrix 
> subtasks based on previously tracked time
> -
>
> Key: JENKINS-13820
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13820
> Project: Jenkins
>  Issue Type: New Feature
>  Components: plugin
> Environment: distributed matrix setup
>Reporter: Roman G
>Assignee: Lucie Votypkova
>  Labels: matrix, plugin
>
> It will be good to have possibility for automatically set order of execution 
> of matrix subtasks based on tracked time(in execution history) - longer 
> subtask must be executed earlier then shorter. I think, it could help to 
> decrease execution time for full matrix task. 
> F.e. I have 2 nodes  and 3 matrix configurations(1,2,3) and estimation time 
> of execution based on history is 1h ,2h, 3h. I suggest to write plugin which 
> set execution order: 3->2->1. In this case, full execution time will be 3h 
> (node 1 - task 3, node 2 - task1+task2). In any other order full execution 
> time will be longer.

--
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-13964) Enhance the posted deliveries polling, so it can work 'as normal'

[l...@praqma.net (JIRA)]

Leif Sorensen created JENKINS-13964:
---

 Summary: Enhance the posted deliveries polling, so it can work 'as 
normal'
 Key: JENKINS-13964
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13964
 Project: Jenkins
  Issue Type: Improvement
  Components: clearcase-ucm
Reporter: Leif Sorensen


The process for posted deliveries is a bit different from normal: on top of 
making the baseline, the developer must issue a Deliver Baseline command. A 
special "Posted deliver" object is then created, and the mastership of the 
development stream is transferred to the integration stream site. The plugin 
will detect the posted delivery, and resume and complete (or cancel) the 
delivery. As a result of this, the mastership of the stream will be transferred 
back to the origin. Notice: The ClearCase posted delivery process does not 
transfer the mastership of the baseline - for that reason the promotion level 
of the baseline cannot be changed, but is left as INITIAL. Tags can also not be 
updated.

The plugin should be enhanced, so it can work in exactly the same way as in a 
single site setup: the developer just creates baselines, and everything else 
happens automatically.

--
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-13716) Default graph configuration for project is not read

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-13716:


Code changed in jenkins
User: Ulli Hafner
Path:
 pom.xml
 src/main/java/hudson/plugins/warnings/WarningsProjectAction.java
http://jenkins-ci.org/commit/warnings-plugin/57d20b53935438e699c4bd3e8872ccd55795bbca
Log:
  [FIXED JENKINS-13716] Fixed file name of default graph configuration.


Compare: https://github.com/jenkinsci/warnings-plugin/compare/f9ca3bb...57d20b5



> Default graph configuration for project is not read
> ---
>
> Key: JENKINS-13716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13716
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: Ulli Hafner
>Assignee: Ulli Hafner
>Priority: Minor
>
> Seems that the defaults for the trend graph that are read from a file don not 
> work anymore.

--
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-13716) Default graph configuration for project is not read

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon resolved JENKINS-13716.


Resolution: Fixed

> Default graph configuration for project is not read
> ---
>
> Key: JENKINS-13716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13716
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: Ulli Hafner
>Assignee: Ulli Hafner
>Priority: Minor
>
> Seems that the defaults for the trend graph that are read from a file don not 
> work anymore.

--
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-12307) Stack Trace when going to main configuration page

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-12307:


Code changed in jenkins
User: Ulli Hafner
Path:
 src/main/java/hudson/plugins/warnings/WarningsPublisher.java
http://jenkins-ci.org/commit/warnings-plugin/17cb850e429c27d6079ffdad9c9e89ab34426c4f
Log:
  [JENKINS-12307] Handle null values in constructor if user does not
select a log file or file parser.




> Stack Trace when going to main configuration page
> -
>
> Key: JENKINS-12307
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12307
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: mwebber
>Assignee: Ulli Hafner
>Priority: Minor
>
> When I go (in the web interface) to the main Jenkins configuration page, a 
> stack trace is generated on the Jenkins console. No adverse results appear on 
> the web page itself. From the stack track, it looks like it is connected to 
> the warnings plugin.
> This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the 
> time of reporting). I have been noticing this stack track for some time now, 
> including under earlier releases (I'm not sure how recently it started).
> The stack trace:
> {noformat}
> 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate
> WARNING: Caught exception evaluating: 
> descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: 
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
> at 
> org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
> at 
> org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
> at 
> org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75)
> at 
> org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
> at 
> org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
> at 
> org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
> at 
> org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
> at 
> hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at 
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
> at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
> at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.d

[JIRA] (JENKINS-12307) Stack Trace when going to main configuration page

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-12307:


Code changed in jenkins
User: Ulli Hafner
Path:
 src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java
http://jenkins-ci.org/commit/warnings-plugin/324d43ddcdd3b80bb85eb52e1d8ff88f7fd8d74e
Log:
  [JENKINS-12307] Show localized name of parser in list box.




> Stack Trace when going to main configuration page
> -
>
> Key: JENKINS-12307
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12307
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: mwebber
>Assignee: Ulli Hafner
>Priority: Minor
>
> When I go (in the web interface) to the main Jenkins configuration page, a 
> stack trace is generated on the Jenkins console. No adverse results appear on 
> the web page itself. From the stack track, it looks like it is connected to 
> the warnings plugin.
> This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the 
> time of reporting). I have been noticing this stack track for some time now, 
> including under earlier releases (I'm not sure how recently it started).
> The stack trace:
> {noformat}
> 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate
> WARNING: Caught exception evaluating: 
> descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: 
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
> at 
> org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
> at 
> org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
> at 
> org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75)
> at 
> org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
> at 
> org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
> at 
> org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
> at 
> org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
> at 
> hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at 
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
> at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270)
> at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
> at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
> 

[JIRA] (JENKINS-13716) Default graph configuration for project is not read

[scm_issue_l...@java.net (JIRA)]

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

SCM/JIRA link daemon commented on JENKINS-13716:


Code changed in jenkins
User: Ulli Hafner
Path:
 src/main/java/hudson/plugins/analysis/graph/UserGraphConfigurationView.java
http://jenkins-ci.org/commit/analysis-core-plugin/b8cc4bfda98847b446d647b5e34ec6cea7df5d3a
Log:
  [JENKINS-13716] Fixed file name of default graph configuration.






> Default graph configuration for project is not read
> ---
>
> Key: JENKINS-13716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13716
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: Ulli Hafner
>Assignee: Ulli Hafner
>Priority: Minor
>
> Seems that the defaults for the trend graph that are read from a file don not 
> work anymore.

--
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-13963) Job executed on Slave node is using JAVA_HOME from Master

[dcor...@allureglobal.com (JIRA)]

David Corbin created JENKINS-13963:
--

 Summary: Job executed on Slave node is using JAVA_HOME from Master
 Key: JENKINS-13963
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13963
 Project: Jenkins
  Issue Type: Bug
  Components: slave-setup
 Environment: Jenkins 1.443 is running on Windows XP. A Jenkins slave 
node is running on Windows.  I have a job that is designated to run only on the 
slave node.
Reporter: David Corbin
Assignee: Kohsuke Kawaguchi


After careful investigation, when "Windows Batch" job or "Execute Shell" 
executes on a slave node, the JAVA_HOME variable the job has set is the same as 
the Jankins Master node, even if the Slave node has it defined otherwise.

--
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-13863) MSBuild is unable to build projects in a different directory

[dartm...@gmail.com (JIRA)]

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

Aaron Laws commented on JENKINS-13863:
--

Josselin Vallet , that workaround works, although I wouldn't call it a 
solution.  Thanks for the advice!

> MSBuild is unable to build projects in a different directory
> 
>
> Key: JENKINS-13863
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13863
> Project: Jenkins
>  Issue Type: Bug
>  Components: msbuild
>Affects Versions: current
> Environment: MS Windows Server 2008
>Reporter: Aaron Laws
>Assignee: kdsweeney
>Priority: Minor
>  Labels: path, plugin
> Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, 
> goodbuild.txt, goodconfig.PNG
>
>
> I use SVN to checkout a project to {{.\proj\}}  and a dependency to 
> {{.\dep\}}.  The {{.sln}} file is at {{.\proj\proj.sln}}.  I us the MsBuild 
> plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a 
> number of variants such as {{.\proj\proj.sln}}). Msbuild fails with 
> {{MSB1009: Project file does not exist.}} However, running a similar command 
> manually succeeds.

--
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-13892) Analysis collector marks some warnings as fixed even though they are not

[ullrich.haf...@gmail.com (JIRA)]

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

Ulli Hafner edited comment on JENKINS-13892 at 5/31/12 12:47 PM:
-

What options did you set in the analysis collector configuration (compute new 
warnings, use delta for new warnings). What are the warning numbers of the 
reference build (the build that new warnings are computed)?

Does this occur in all of your projects and in all builds? Or is this just a 
singular problem?

  was (Author: drulli):
What options did you set in the analysis collector configuration (compute 
new warnings, use delta for new warnings). What are the warning numbers of the 
reference build?
  
> Analysis collector marks some warnings as fixed even though they are not
> 
>
> Key: JENKINS-13892
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13892
> Project: Jenkins
>  Issue Type: Bug
>  Components: analysis-collector, analysis-core
> Environment: Jenkins core version: 1.410
> Static Code Analysis Plug-ins -- 1.38
> FindBugs Plugin -- 4.36
> Warnings Plugin-- 3.28
> Analysis Collector Plugin--- 1.19
>Reporter: naveen karnati
>Assignee: Ulli Hafner
> Attachments: compilerwarnings.JPG, findbugsresult.JPG, 
> fixed_warnings_tab.JPG, static_analysis_result_error.JPG
>
>
> As mentioned over comment 
> "https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins?focusedCommentId=60918774&#comment-60918774";,
>  the "Static Analysis Result" is showing wrong. 
> We (at our company) are using Jenkins core version 1.410 and "Static Code 
> Analysis Plug-ins" plugin installed is v1.38. Somehow the result overview is 
> showing wrong. eg: Total warnings are 52, however in the details it shows as 
> 40. Surprisingly, the difference 12 warnings went into fixed (even without 
> any change of 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-13959) StackOverflowException on Job Finish

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13959:
--

Not much help. Could you attach one of you failing jobs' config.xml? Feel free 
to obsucure any sensitive values, but leave the general structure of fields as 
they are.

> StackOverflowException on Job Finish
> 
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following 
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
>   at 
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
>   at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
>   at java.util.Calendar.updateTime(Calendar.java:2495)
>   at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
>   at java.util.Calendar.getMillisOf(Calendar.java:2512)
>   at java.util.Calendar.equals(Calendar.java:1892)
>   at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report 
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email 
> notification" setting, storing the configuration and then re-add the 
> notification setting, so perhaps it has something to do with the notification 
> part in jenkins itself.
> PS: The concerned Jobs do not all use CVS, some of them are git-only but get 
> the exact same stacktrace as reported above.

--
This message is automat

[JIRA] (JENKINS-13962) Add exclusion list for which dependencies will trigger a build

[rol...@stackandheap.com (JIRA)]

Roland Zwaga created JENKINS-13962:
--

 Summary: Add exclusion list for which dependencies will trigger a 
build
 Key: JENKINS-13962
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13962
 Project: Jenkins
  Issue Type: Improvement
  Components: maven-dependency-update-trigger
Affects Versions: current
Reporter: Roland Zwaga
Assignee: olamy
Priority: Minor


It would be really nice if we can add an exclusion list to this plugin.
A list of artifact ids to that will NOT trigger a build.
For example: I have a use-case where all my poms reference the same parent pom.
Now, when I commit and update to the parent pom, ALL of my project will be 
triggered, which is not always desirable.

--
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-13803) PRQA Plugin fails during the publishing phase with NULL pointer exception

[m...@praqma.net (JIRA)]

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

Mads Nielsen resolved JENKINS-13803.


 Assignee: Mads Nielsen  (was: Lars Kruse)
Fix Version/s: current
   Resolution: Fixed

Fixed in 1.0.3

> PRQA Plugin fails during the publishing phase with NULL pointer exception
> -
>
> Key: JENKINS-13803
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13803
> Project: Jenkins
>  Issue Type: Bug
>  Components: prqa
> Environment: Master: linux
> Slave: Windows 7
> Jenkins 1.441
>Reporter: Julian Requejo
>Assignee: Mads Nielsen
> Fix For: current
>
>
> PRQA plugin generates reports correctly, but fails during publishing phase.
> {noformat}
> At revision 1572
> no change for https://xx/xx since the previous build
> This job will create a report with the following selected parameters:
> QAR selected project file:Sources\QAC\xx\xx.prj
> QAR selected product: QAC
> QAR selected report type: Compliance
> Beginning report generation with the following command:
>  qaw QAC "Sources\QAC\xx\xx.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\xx_QAC -po 
> qar::viewing_program=dummy -po qar::report_format=xhtml" 
> Viewer "dummy" not available, result will not be rendered.
> Generating - Please wait...
> Writing c:\_dev\jenkins-int\workspace\xx_QAC\Compliance Report.xml
> Writing c:\_dev\jenkins-int\workspace\xx_QAC\Compliance Report.xhtml
> Writing c:\_dev\jenkins-int\workspace\xx_QAC\Compliance Report-Main.xhtml
> Finished remote reporting.
> Found report. Attempting to copy Compliance Report.xhtml to artifacts 
> directory: /home/xx/.jenkins/jobs/xx_QAC/builds/2012-05-16_17-11-12/archive
> Attempting to copy report to following target: Compliance Report.xhtml
> Succesfully copied report
> ERROR: Publisher net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier aborted 
> due to exception
> java.lang.NullPointerException
>   at 
> net.praqma.jenkins.plugin.prqa.notifier.PRQANotifier.perform(PRQANotifier.java:240)
>   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)
> Notifying upstream projects of job completion
> Finished: FAILURE
> {noformat}
> I have tested this using three configurations, all with Jenkins 1.441
> - Single Jenkins web app running on my local machine (Windows 7): it works
> - Master-slave configuration, *both* on my local machine (Windows 7), slave 
> as a user process: it works
> - Master-slave configuration, master on a Linux box, slave on my local 
> Windows 7 machine (Windows 7), slave as a user process: it does *not* work 
> and triggers the error above.
> I could try upgrading to a newer Jenkins, but I'd strongly prefer not to 
> unless shown to be essential.
> I'll be happy to provide further logs. 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-13952) Coverity plugin cannot connect to CIM instance

[tma...@nyx.com (JIRA)]

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

Tim Mason resolved JENKINS-13952.
-

Resolution: Incomplete

Jenkins was using OpenJDK, seems like the Coverity plugin doesn't like this. I 
change to Sun JDK and the plugin worked OK.
So although there might be a bug somewhere, I am happy to close this issue as 
the problem is resolved.


> Coverity plugin cannot connect to CIM instance
> --
>
> Key: JENKINS-13952
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13952
> Project: Jenkins
>  Issue Type: Bug
>  Components: coverity
>Reporter: Tim Mason
>
> Hi,
> I installed the coverity plugin.
> On the Jenkins Configure System, after I enter the details for the Coverity 
> CIM instance and click the Check button, I get "unexpected error occurred". 
> Clicking Show Details gives the following:
> java.lang.NoClassDefFoundError: Could not initialize class 
> com.sun.xml.wss.impl.SecurableSoapMessage
>   at 
> com.sun.xml.wss.ProcessingContext.setSOAPMessage(ProcessingContext.java:223)
>   at 
> com.sun.xml.wss.impl.misc.XWSSProcessor2_0Impl.createProcessingContext(XWSSProcessor2_0Impl.java:153)
>   at 
> jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:97)
>   at 
> jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:40)
>   at 
> com.sun.xml.internal.ws.handler.HandlerProcessor.callHandleMessage(Unknown 
> Source)
>   at 
> com.sun.xml.internal.ws.handler.HandlerProcessor.callHandlersRequest(Unknown 
> Source)
> etc
> Any idea how I can fix this?
> 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-12577) Email notification hangs due to NullPointerException

[costincarai...@gmail.com (JIRA)]

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

Costin Caraivan resolved JENKINS-12577.
---

Resolution: Cannot Reproduce

Not getting NPEs after an upgrade of the Perforce plugin.

> Email notification hangs due to NullPointerException
> 
>
> Key: JENKINS-12577
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12577
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: Windows 2008 Server x64, Java 1.6.0_25
>Reporter: Costin Caraivan
>Priority: Blocker
> Attachments: template.jelly
>
>
> We have an email notification which uses a Jelly template. So far it worked 
> ok, but recently we started getting these:
> Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher 
> sendMail
> WARNING: Could not send email.
> java.lang.NullPointerException
>   at hudson.model.Slave.createLauncher(Slave.java:311)
>   at 
> hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60)
>   at 
> hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100)
>   at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203)
>   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647)
>   at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
>   at hudson.model.Run.run(Run.java:1448)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:230)

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

[JIRA] (JENKINS-12577) Email notification hangs due to NullPointerException

[costincarai...@gmail.com (JIRA)]

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

Costin Caraivan edited comment on JENKINS-12577 at 5/31/12 10:56 AM:
-

Unfortunately I do not have the build log anymore. From what I remember the 
output was:

Sending email to: $OUR-CONFIGURED-RECIPIENTS

Then nothing and the build would get stuck.
We're not getting the NPE anymore after an upgrade of the Perforce plugin, so 
you can close this.

  was (Author: ccaraivan):
Unfortunately I do not have the build log anymore. From what I remember the 
output was:

Sending email to: $OUR-CONFIGURED-RECIPIENTS

Then nothing and the build would get stuck.
We're not getting the NPE anymore, so you can close this.
  
> Email notification hangs due to NullPointerException
> 
>
> Key: JENKINS-12577
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12577
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: Windows 2008 Server x64, Java 1.6.0_25
>Reporter: Costin Caraivan
>Priority: Blocker
> Attachments: template.jelly
>
>
> We have an email notification which uses a Jelly template. So far it worked 
> ok, but recently we started getting these:
> Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher 
> sendMail
> WARNING: Could not send email.
> java.lang.NullPointerException
>   at hudson.model.Slave.createLauncher(Slave.java:311)
>   at 
> hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60)
>   at 
> hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100)
>   at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203)
>   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647)
>   at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
>   at hudson.model.Run.run(Run.java:1448)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:230)

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

[JIRA] (JENKINS-12577) Email notification hangs due to NullPointerException

[costincarai...@gmail.com (JIRA)]

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

Costin Caraivan commented on JENKINS-12577:
---

Unfortunately I do not have the build log anymore. From what I remember the 
output was:

Sending email to: $OUR-CONFIGURED-RECIPIENTS

Then nothing and the build would get stuck.
We're not getting the NPE anymore, so you can close this.

> Email notification hangs due to NullPointerException
> 
>
> Key: JENKINS-12577
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12577
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: Windows 2008 Server x64, Java 1.6.0_25
>Reporter: Costin Caraivan
>Priority: Blocker
> Attachments: template.jelly
>
>
> We have an email notification which uses a Jelly template. So far it worked 
> ok, but recently we started getting these:
> Jan 25, 2012 2:11:23 PM hudson.plugins.emailext.ExtendedEmailPublisher 
> sendMail
> WARNING: Could not send email.
> java.lang.NullPointerException
>   at hudson.model.Slave.createLauncher(Slave.java:311)
>   at 
> hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:60)
>   at 
> hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100)
>   at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:488)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243)
>   at 
> hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203)
>   at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:694)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:669)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:647)
>   at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
>   at hudson.model.Run.run(Run.java:1448)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:230)

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

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

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13227:
--

Amir: I'm going to fix the issue with losing settings when upgrading from the 
previous version to the current version then do a release. I'll look at your 
other issue after I've done the release as otherwise we'll never get this fix 
live.

> 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-13959) StackOverflowException on Job Finish

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13959:
--

To help narrow down this issue, could you provide the stack trace for the 
exception you're getting with GIT and also let us know which version of the CVS 
plugin and GIT plugin?

> StackOverflowException on Job Finish
> 
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
>  Issue Type: Bug
>  Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following 
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
>   at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
>   at 
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
>   at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
>   at java.util.Calendar.updateTime(Calendar.java:2495)
>   at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
>   at java.util.Calendar.getMillisOf(Calendar.java:2512)
>   at java.util.Calendar.equals(Calendar.java:1892)
>   at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
>   at java.util.AbstractList.equals(AbstractList.java:524)
>   at 
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
>   at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report 
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email 
> notification" setting, storing the configuration and then re-add the 
> notification setting, so perhaps it has something to do with the notification 
> part in jenkins itself.
> PS: The concerned Jobs do not all use CVS, some of them are git-only but get 
> the exact same stacktrace as reported above.

--
This message i

[JIRA] (JENKINS-13961) Fitnesse exception loading resource testResults.vm if job name contains a comma (,)

[garethowen_cur...@hotmail.com (JIRA)]

Gareth Curtis created JENKINS-13961:
---

 Summary: Fitnesse exception loading resource testResults.vm if job 
name contains a comma (,)
 Key: JENKINS-13961
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13961
 Project: Jenkins
  Issue Type: Bug
  Components: fitnesse
Affects Versions: current
 Environment: tested on Windows 7 32 bit and Windows Server 2008 R2 64 
bit
Reporter: Gareth Curtis
Priority: Trivial


If the name of a job (and therefore also the workspace folder) includes a 
comma, an exception occurs (when the FitNesse plugin attempts to read the test 
results?)

Workaround is easy - just rename the job. But thought it best to document the 
issue, it may save someone else some time.

A copy from console output below:


FitNesse (v20111026) Started...
port:  8081
root page: fitnesse.wiki.FileSystemPage at C:\Program 
Files\Jenkins\jobs\Run engage.installer, - from nightly build 
folder\workspace/FitNesseRoot
logger:none
authenticator: fitnesse.authentication.PromiscuousAuthenticator
html page factory: fitnesse.html.HtmlPageFactory
page version expiration set to 14 days.

Connnecting to 
http://localhost:8081/EngageAcceptanceTests.AuthenticationWithLoginTests?test&format=xml&includehtml
Connected: 200/OK
Xml results saved as windows-1252 to C:\Program Files\Jenkins\jobs\Run 
engage.installer, - from nightly build folder\workspace\fitnesseResults.xml
org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource 'testResults.vm'
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:483)
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354)
at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400)
at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1380)
at 
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:401)
at 
fitnesse.responders.run.formatters.XmlFormatter.writeResults(XmlFormatter.java:132)
at 
fitnesse.responders.run.formatters.XmlFormatter.writeResults(XmlFormatter.java:117)
at 
fitnesse.responders.run.formatters.PageHistoryFormatter.testComplete(PageHistoryFormatter.java:27)
at 
fitnesse.responders.run.formatters.CompositeFormatter.testComplete(CompositeFormatter.java:65)
at 
fitnesse.responders.run.MultipleTestsRunner.testComplete(MultipleTestsRunner.java:238)
at fitnesse.responders.run.TestSystem.testComplete(TestSystem.java:116)
at 
fitnesse.responders.run.slimResponder.SlimTestSystem.runTestsAndGenerateHtml(SlimTestSystem.java:228)
at 
fitnesse.responders.run.MultipleTestsRunner.executeTestSystemPages(MultipleTestsRunner.java:140)
at 
fitnesse.responders.run.MultipleTestsRunner.startTestSystemAndExecutePages(MultipleTestsRunner.java:120)
at 
fitnesse.responders.run.MultipleTestsRunner.executePagesInTestSystem(MultipleTestsRunner.java:106)
at 
fitnesse.responders.run.MultipleTestsRunner.internalExecuteTestPages(MultipleTestsRunner.java:86)
at 
fitnesse.responders.run.MultipleTestsRunner.executeTestPages(MultipleTestsRunner.java:58)
at 
fitnesse.responders.run.TestResponder.performExecution(TestResponder.java:145)
at 
fitnesse.responders.run.TestResponder.doSending(TestResponder.java:45)
at 
fitnesse.responders.ChunkingResponder.startSending(ChunkingResponder.java:67)
at 
fitnesse.responders.ChunkingResponder.access$000(ChunkingResponder.java:17)
at 
fitnesse.responders.ChunkingResponder$RespondingRunnable.run(ChunkingResponder.java:106)
at java.lang.Thread.run(Unknown Source)

31.05.2012 11:40:24 org.apache.velocity.runtime.log.JdkLogChute log
SCHWERWIEGEND: ResourceManager : unable to find resource 'testResults.vm' in 
any resource loader.
31.05.2012 11:40:24 org.apache.velocity.runtime.log.JdkLogChute log
SCHWERWIEGEND: ResourceManager : unable to find resource 'testResults.vm' in 
any resource loader.
org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource 'testResults.vm'
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:483)
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354)
at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400)
at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1380)
at 
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:401)
at 
fitnesse.responders.run.formatters.XmlFormatter.writeResults(XmlFormatter.

[JIRA] (JENKINS-4740) 404 when not logged in when clicking link in hudson-e-mail

[eren...@global-blue.com (JIRA)]

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

Edwin Renner commented on JENKINS-4740:
---

we are facing the same problem, any progress on this issue or a workaround?
thanks

> 404 when not logged in when clicking link in hudson-e-mail
> --
>
> Key: JENKINS-4740
> URL: https://issues.jenkins-ci.org/browse/JENKINS-4740
> Project: Jenkins
>  Issue Type: Bug
>  Components: gui
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: 2sober
> Attachments: 4740.patch, screenshot.jpg
>
>
> When a user is not logged into hudson gui and clicks a link in a hudson-email 
> like:
> See 
> He gets a 404 error:
> HTTP Status 404 -
> type Status report
> message
> description The requested resource () is not available.
> Apache Tomcat/6.0.18

--
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-13863) MSBuild is unable to build projects in a different directory

[josselin.val...@gmail.com (JIRA)]

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

Josselin Vallet edited comment on JENKINS-13863 at 5/31/12 9:01 AM:


I had the same issue,

I solved this by using the environment variable WORKSPACE and setting the 
solution path to "%WORKSPACE%\proj\proj.sln".

  was (Author: burlhock):
I had the same problem,

I solved this by using the environment variable WORKSPACE and setting the 
solution path to "%WORKSPACE%\proj\proj.sln".
  
> MSBuild is unable to build projects in a different directory
> 
>
> Key: JENKINS-13863
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13863
> Project: Jenkins
>  Issue Type: Bug
>  Components: msbuild
>Affects Versions: current
> Environment: MS Windows Server 2008
>Reporter: Aaron Laws
>Assignee: kdsweeney
>Priority: Minor
>  Labels: path, plugin
> Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, 
> goodbuild.txt, goodconfig.PNG
>
>
> I use SVN to checkout a project to {{.\proj\}}  and a dependency to 
> {{.\dep\}}.  The {{.sln}} file is at {{.\proj\proj.sln}}.  I us the MsBuild 
> plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a 
> number of variants such as {{.\proj\proj.sln}}). Msbuild fails with 
> {{MSB1009: Project file does not exist.}} However, running a similar command 
> manually succeeds.

--
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-8965) Send mail on a failed promotion

[daniel.frod...@diabol.se (JIRA)]

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

Daniel Fröding commented on JENKINS-8965:
-

When promotion fails, this behavior prevents and feedback to be sent to the 
person that caused the failure.
A solution could be to add a separate global action with options to trigger 
notifications about failures in any promotion step.

> Send mail on a failed promotion
> ---
>
> Key: JENKINS-8965
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8965
> Project: Jenkins
>  Issue Type: New Feature
>  Components: promoted-builds
>Reporter: kirill_evstigneev
>Priority: Minor
>
> Generally - to trigger an action on the promotion failure.
> Sending a mail is a most obvious example.
> Right now a promotion is a sequential process. Any failure stops it. So 
> Email-ext step is executed only on a promotion success and only for "Success" 
> trigger.

--
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-13959) StackOverflowException on Job Finish

[simon.schlach...@ergon.ch (JIRA)]

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

Simon Schlachter updated JENKINS-13959:
---

Description: 
Since upgrading to jenkins 1.465 we get in some of our jobs the following 
stacktrace:
{noformat}
FATAL: null
java.lang.StackOverflowError
at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
at 
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
at java.util.Calendar.updateTime(Calendar.java:2495)
at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
at java.util.Calendar.getMillisOf(Calendar.java:2512)
at java.util.Calendar.equals(Calendar.java:1892)
at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
at java.util.AbstractList.equals(AbstractList.java:524)
at 
hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
...
{noformat}

The Exception happens when the Job itself has finished and is about to report 
results to e-mail receivers.

We were able to workaround the issue by removing the "send email notification" 
setting, storing the configuration and then re-add the notification setting, so 
perhaps it has something to do with the notification part in jenkins itself.

PS: The concerned Jobs do not all use CVS, some of them are git-only but get 
the exact same stacktrace as reported above.

  was:
Since upgrading to jenkins 1.465 we get in some of our jobs the following 
stacktrace:
{noformat}
FATAL: null
java.lang.StackOverflowError
at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
at 
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
at java.util.Calendar.updateTime(Calendar.java:2495)
at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
at java.util.Calendar.getMillisOf(Calendar.java:2512)
at java.util.Calendar

[JIRA] (JENKINS-13863) MSBuild is unable to build projects in a different directory

[josselin.val...@gmail.com (JIRA)]

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

Josselin VALLET commented on JENKINS-13863:
---

I had the same problem,

I solved this by using the environment variable WORKSPACE and setting the 
solution path to "%WORKSPACE%\proj\proj.sln".

> MSBuild is unable to build projects in a different directory
> 
>
> Key: JENKINS-13863
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13863
> Project: Jenkins
>  Issue Type: Bug
>  Components: msbuild
>Affects Versions: current
> Environment: MS Windows Server 2008
>Reporter: Aaron Laws
>Assignee: kdsweeney
>Priority: Minor
>  Labels: path, plugin
> Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, 
> goodbuild.txt, goodconfig.PNG
>
>
> I use SVN to checkout a project to {{.\proj\}}  and a dependency to 
> {{.\dep\}}.  The {{.sln}} file is at {{.\proj\proj.sln}}.  I us the MsBuild 
> plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a 
> number of variants such as {{.\proj\proj.sln}}). Msbuild fails with 
> {{MSB1009: Project file does not exist.}} However, running a similar command 
> manually succeeds.

--
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-13892) Analysis collector marks some warnings as fixed even though they are not

[ullrich.haf...@gmail.com (JIRA)]

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

Ulli Hafner commented on JENKINS-13892:
---

What options did you set in the analysis collector configuration (compute new 
warnings, use delta for new warnings). What are the warning numbers of the 
reference build?

> Analysis collector marks some warnings as fixed even though they are not
> 
>
> Key: JENKINS-13892
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13892
> Project: Jenkins
>  Issue Type: Bug
>  Components: analysis-collector, analysis-core
> Environment: Jenkins core version: 1.410
> Static Code Analysis Plug-ins -- 1.38
> FindBugs Plugin -- 4.36
> Warnings Plugin-- 3.28
> Analysis Collector Plugin--- 1.19
>Reporter: naveen karnati
>Assignee: Ulli Hafner
> Attachments: compilerwarnings.JPG, findbugsresult.JPG, 
> fixed_warnings_tab.JPG, static_analysis_result_error.JPG
>
>
> As mentioned over comment 
> "https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins?focusedCommentId=60918774&#comment-60918774";,
>  the "Static Analysis Result" is showing wrong. 
> We (at our company) are using Jenkins core version 1.410 and "Static Code 
> Analysis Plug-ins" plugin installed is v1.38. Somehow the result overview is 
> showing wrong. eg: Total warnings are 52, however in the details it shows as 
> 40. Surprisingly, the difference 12 warnings went into fixed (even without 
> any change of 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-13892) Analysis collector marks some warnings as fixed even though they are not

[ullrich.haf...@gmail.com (JIRA)]

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

Work on JENKINS-13892 started by Ulli Hafner.

> Analysis collector marks some warnings as fixed even though they are not
> 
>
> Key: JENKINS-13892
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13892
> Project: Jenkins
>  Issue Type: Bug
>  Components: analysis-collector, analysis-core
> Environment: Jenkins core version: 1.410
> Static Code Analysis Plug-ins -- 1.38
> FindBugs Plugin -- 4.36
> Warnings Plugin-- 3.28
> Analysis Collector Plugin--- 1.19
>Reporter: naveen karnati
>Assignee: Ulli Hafner
> Attachments: compilerwarnings.JPG, findbugsresult.JPG, 
> fixed_warnings_tab.JPG, static_analysis_result_error.JPG
>
>
> As mentioned over comment 
> "https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins?focusedCommentId=60918774&#comment-60918774";,
>  the "Static Analysis Result" is showing wrong. 
> We (at our company) are using Jenkins core version 1.410 and "Static Code 
> Analysis Plug-ins" plugin installed is v1.38. Somehow the result overview is 
> showing wrong. eg: Total warnings are 52, however in the details it shows as 
> 40. Surprisingly, the difference 12 warnings went into fixed (even without 
> any change of 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-13960) Job Jenkins unable to access secure svn repository

[riadh...@yahoo.fr (JIRA)]

riadh mnasri created JENKINS-13960:
--

 Summary: Job Jenkins unable to access secure svn repository
 Key: JENKINS-13960
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13960
 Project: Jenkins
  Issue Type: Bug
  Components: subversion
 Environment: Jenkins ver. 1.454, apache 2, Redmine 1.3.1 and 
Subversion 1.6.11
Reporter: riadh mnasri
Priority: Critical


Hello,

I'm using Jenkins ver. 1.454, apache 2, redmine 1.3.1 and subversion 1.6.11. I 
would like to secure access for my svn repositories (I'm using Redmine module 
authenticating users having accounts in LDAP directory).

I have disabled anonymous access and my Jenkins jobs are no longer working.

I have an error like the following :

Unable to access http:// mysvnsources.xxx.fra/myproject/trunk : svn: OPTIONS 
/myproject/trunk failed

org.tmatesoft.svn.core.SVNCancelException: svn: OPTIONS /myproject/trunk failed

at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:287)

at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276)

at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264)

at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)

at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)

at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)

at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97)

at 
hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1957)

at 
hudson.scm.SubversionSCM$DescriptorImpl.doCheckRemote(SubversionSCM.java:1891)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at 
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)

at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)

at 
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)

at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)

at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)

at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)

at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)

at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)

at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)

at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)

at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)

at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)

at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)

at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)

at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)

at org.kohsuke.stapler.Stapler.service(Stapler.java:159)

   

Is there any way, in Jenkins, to change the default behaviour (anonymous 
access) by using a user having read acess to my svn repositories  or any other 
solution ?

Thank you in advance for your help?


Best regards,

Riadh

--
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-9539) Quality Center Plugin Error: runTestSet.vbs(133, 5) Microsoft VBScript runtime error: ActiveX component can't create object: 'TDApiOle80.TDConnection'

[anthony.c...@sita.aero (JIRA)]

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

Anthony Carr commented on JENKINS-9539:
---

Could someone tell me if a fix/workaround is available for this issue?

> Quality Center Plugin Error: runTestSet.vbs(133, 5) Microsoft VBScript 
> runtime error: ActiveX component can't create object: 
> 'TDApiOle80.TDConnection'
> --
>
> Key: JENKINS-9539
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9539
> Project: Jenkins
>  Issue Type: Bug
>  Components: qc
>Affects Versions: current
> Environment: Windows Vista Enterprise SP2 x64
> Mozilla Firefox 4.0 & Internet Explorer 8
> Jenkins ver. 1.409
> qc plugin 1.0 (script runTestSet.vbs used is version fixed in issue #9267)
>Reporter: Pablo García
>Assignee: Daniel Petisme
>Priority: Minor
>
> ERROR trying to create the object TDApiOle80.TDConnection in Class 
> QCTestRunner.
>   Sub Class_Initialize
> errors = 0
> Set tdConnection = CreateObject("TDApiOle80.TDConnection")
> timestamp = CStr(Now)
>   End Sub
>  
> Error message reported is next:
> [TRUNK] $ cscript /nologo xxx\runTestSet.vbs http://xxx/qcbin 
> pablo.garcia_hp.com  xxx xxx "xxx" Test1 qcreport-Test1-7.xml 
> xxx\runTestSet.vbs(133, 5) Microsoft VBScript runtime error: ActiveX 
> component can't create object: 'TDApiOle80.TDConnection'
> Cant create TDConnection Object

--
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-13876) GNU Compiler Warnings also catches Java exception

[ullrich.haf...@gmail.com (JIRA)]

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

Ulli Hafner resolved JENKINS-13876.
---

Resolution: Not A Defect

I see no other solution for this problem (besides the workaround). If you have 
an idea that works in general please reopen.

> GNU Compiler Warnings also catches Java exception 
> --
>
> Key: JENKINS-13876
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13876
> Project: Jenkins
>  Issue Type: Bug
>  Components: warnings
>Reporter: Sylvestre Ledru
>Assignee: Ulli Hafner
>Priority: Minor
> Attachments: bug-warning.png
>
>
> With a project using both gcc and javac, the "GNU Compiler Warnings" catches 
> also the Java warnings.
> CF screenshot

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