[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails

[stephen.morri...@intecbilling.com (JIRA)]

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

Stephen Morrison commented on JENKINS-13241:


I don't believe the symlink bug fix fixes the issue mentioned in some of the 
comments here.  I just installed the snapshot that has 13202 in it, and 
archiving of artifacts still fails on HP and AIX with the 
UnsupportedOperationException error.

 Artifact archiving from remote slave fails
 --

 Key: JENKINS-13241
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13241
 Project: Jenkins
  Issue Type: Bug
  Components: core
Reporter: Vyacheslav Karpukhin

 Since 1.456 jenkins stopped archiving artifacts from remote slave. This 
 affects both 1.456 and 1.457, works correctly with 1.455.
 ERROR: Failed to archive artifacts: build/Release/*.app/**/*
 hudson.util.IOException2: hudson.util.IOException2: Failed to extract 
 /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/*
   at hudson.FilePath.readFromTar(FilePath.java:1817)
   at hudson.FilePath.copyRecursiveTo(FilePath.java:1729)
   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:1435)
   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: java.io.IOException: Failed to chmod 
 /mnt/storage/.jenkins/jobs/NGB_Queues/builds/2012-03-27_03-11-27/archive/build/Release/NGB
  
 Queues.app/Contents/Frameworks/BWToolkitFramework.framework/BWToolkitFramework
  : No such file or directory
   at hudson.FilePath._chmod(FilePath.java:1248)
   at hudson.FilePath.readFromTar(FilePath.java:1813)
   ... 12 more
   at hudson.FilePath.copyRecursiveTo(FilePath.java:1736)
   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:1435)
   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: java.util.concurrent.ExecutionException: java.io.IOException: Pipe 
 is already closed
   at hudson.remoting.Channel$2.adapt(Channel.java:714)
   at hudson.remoting.Channel$2.adapt(Channel.java:709)
   at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
   at hudson.FilePath.copyRecursiveTo(FilePath.java:1732)
   ... 11 more
 Caused by: java.io.IOException: Pipe is already closed
   at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83)
   at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171)
   at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118)
   at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103)
   at 
 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
   at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
   at 
 java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161)
   at 
 java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
   at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
   at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
   at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410)
   at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351)
   at 
 hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356)
   at 
 hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137)
   at 
 

[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-tabpanelfocusedCommentId=162879#comment-162879
 ] 

Michael Clarke commented on JENKINS-13227:
--

I was reviewing the CVS manual last night and it doesn't provide much insight. 
I can't find suitable free CVS hosting on the internet so I'm going to have to 
bite-the-bullet and try and setup a CVS server on my computer (my previous 
setup was lost when my primary computer died). Since I don't have access to 
your CVS server, could you confirm the setup (CVS Server version, 
authentication mechanism, how you connect etc) and also confirm that this issue 
only seems to happen on branches (polling seems to work on the head). 

Thanks

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

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

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

amit anand commented on JENKINS-13737:
--

I am facing same problem with Jenkins ver. 1.463 and Jenkins ver. 1.464 with 
Chrome browser19.0.1084.46 m

Work around is also not working

 Javascript error when selecting Editable Email Notification
 -

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

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

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

[JIRA] (JENKINS-13808) Status code 404 jenkins in v1.462 after login

[huen.l...@iproperty.com (JIRA)]

Ray Chan created JENKINS-13808:
--

 Summary: Status code 404 jenkins in v1.462 after login
 Key: JENKINS-13808
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13808
 Project: Jenkins
  Issue Type: Bug
  Components: other
Reporter: Ray Chan


Is only showing:
Exception: 
Stacktrace:
(none)

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

[JIRA] (JENKINS-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

Jon Cairns created JENKINS-13809:


 Summary: Template variables are permanently overwritten on first 
use
 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: jenkins-plugin-runtime
Affects Versions: current
 Environment: Should happen on all systems and versions.
Reporter: Jon Cairns
Assignee: Jon Cairns


Meme configurations that include template variables such as ${project} will 
be overwritten with the actual name of the project that first uses that Meme, 
as the Meme object is not copied/cloned, and it is automatically saved. The fix 
is to create a copy of the object and use that for the Meme generation.

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

Re: [JIRA] (JENKINS-13808) Status code 404 jenkins in v1.462 after login

[Niranjan Bansal]

Once you login you may be directed to the default view or job that no
longer exist. Please check and preferably share the screenshot

Thanks
Niranjan

On Thu, May 17, 2012 at 1:32 PM, huen.l...@iproperty.com (JIRA) 
nore...@jenkins-ci.org wrote:

 Ray Chan created JENKINS-13808:
 --

 Summary: Status code 404 jenkins in v1.462 after login
 Key: JENKINS-13808
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13808
 Project: Jenkins
  Issue Type: Bug
  Components: other
Reporter: Ray Chan


 Is only showing:
 Exception:
 Stacktrace:
 (none)

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





-- 
Regards
Niranjan Bansal

[JIRA] (JENKINS-13810) Maven modules marked to wrong build when running concurrent job

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

Jyrki Puttonen created JENKINS-13810:


 Summary: Maven modules marked to wrong build when running 
concurrent job
 Key: JENKINS-13810
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13810
 Project: Jenkins
  Issue Type: Bug
  Components: concurrent-build, maven
Reporter: Jyrki Puttonen
Assignee: Kohsuke Kawaguchi


I have a Maven project build with one module, named jenkins-test. This module 
contains one test, which fails everytime (assertTrue(false) :)). There is a 
problem when this project is executed with Execute concurrent builds if 
necessary turned on and when multiple jobs are started at same time. Multiple 
builds start and finish, but some of these jobs are completed succesfully and 
some are marked as failed. What I see in the build status page is something 
like this:

(Success) Build #180 (May 12, 2012 8:17:09 PM)
...
Module Builds
jenkins-test (didn't run)

(Success) Build #181 (May 12, 2012 8:17:12 PM)
...
Module Builds
(disabled) jenkins-test (didn't run)

(Unstable) Build #182 (May 12, 2012 8:17:19 PM)
...
Module Builds
jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184

Logs show that the builds were executed properly (commit ids are right, and 
[ERROR] There are test failures. is there). The next build then gets build 
number #187.

In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push 
multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same 
time. I don't know if you can duplicate this behavior without Gerrit, though.

Currently MavenModule and MavenModuleSet have their own build numbers, which 
are increment when a new module is built. These might get mixed up when 
multiple builds are executed concurrently. Multiple MavenModuletSets are built 
starting at the same time, and some how the numbering of MavenModules gets out 
of sync.

The commit in 
https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4
 fixes this, but I haven't tested it other cases than mine and I don't think 
that I'm qualified to change something that is this deeply on the jenkins core 
:) The commit probably has some unnecessary bits in it too at the moment. So I 
don't think that it should be merged :)

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

[JIRA] (JENKINS-13811) System Message alignment differs if user is not logged in

[sebastian.moel...@gmx.de (JIRA)]

Sebastian Möller created JENKINS-13811:
--

 Summary: System Message alignment differs if user is not logged in
 Key: JENKINS-13811
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13811
 Project: Jenkins
  Issue Type: Bug
  Components: gui
Affects Versions: current
Reporter: Sebastian Möller
Priority: Trivial
 Attachments: system_message_user_logged_in.png, 
system_message_user_not_logged_in.png

Jenkins Version: 1.464

The white space area between the System Message and the panel below is 
missing if the user is not logged in.

See attachments for an example.

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

[JIRA] (JENKINS-13811) System Message alignment differs if user is not logged in

[smoo...@googlemail.com (JIRA)]

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

Sebastian Möller updated JENKINS-13811:
---

Description: 
Jenkins version: 1.464

The white space area between the System Message and the panel below is 
missing if the user is not logged in.

See attachments for an example.

  was:
Jenkins Version: 1.464

The white space area between the System Message and the panel below is 
missing if the user is not logged in.

See attachments for an example.


 System Message alignment differs if user is not logged in
 -

 Key: JENKINS-13811
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13811
 Project: Jenkins
  Issue Type: Bug
  Components: gui
Affects Versions: current
Reporter: Sebastian Möller
Priority: Trivial
 Attachments: system_message_user_logged_in.png, 
 system_message_user_not_logged_in.png


 Jenkins version: 1.464
 The white space area between the System Message and the panel below is 
 missing if the user is not logged in.
 See attachments for an example.

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

[JIRA] (JENKINS-13549) Duplicate test results are shown for grails projectsgr

[raviteja.lokin...@gmail.com (JIRA)]

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

Ravi Teja Lokineni commented on JENKINS-13549:
--

This started happening recently. Will update that configuration and see.

 Duplicate test results are shown for grails projectsgr
 --

 Key: JENKINS-13549
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13549
 Project: Jenkins
  Issue Type: Bug
  Components: core, grails
Reporter: Ravi Teja Lokineni
Assignee: jeffg2one
  Labels: grails
 Attachments: dup_tests.png, dup_tests_1.png, dup_tests_1.png


 This started happening recently. PFA the attached screenshots. Each failed 
 testcase is printed twice.

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

[JIRA] (JENKINS-9494) Configure System hangs with LOADING gray div covering top half of settings

[jenkins...@photono.de (JIRA)]

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

Andreas Katzig commented on JENKINS-9494:
-

Encountered the same today. Should be possible to fix ...

 Configure System hangs with LOADING gray div covering top half of settings
 

 Key: JENKINS-9494
 URL: https://issues.jenkins-ci.org/browse/JENKINS-9494
 Project: Jenkins
  Issue Type: Bug
  Components: infrastructure
Affects Versions: current
 Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7) 
 (6b20-1.9.7-0ubuntu1)
 OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)
 AWS EC2 cloud instance machine
 package installed by the recommended apt-get instructions on jenkins-ci.org. 
 apt-show says:
 Package: jenkins
 Priority: extra
 Section: devel
 Installed-Size: 37480
 Maintainer: Kohsuke Kawaguchi k...@kohsuke.org
 Architecture: all
 Version: 1.404
 Replaces: hudson
 Depends: daemon, adduser, psmisc, java2-runtime
 Conflicts: hudson
 Filename: binary/jenkins_1.404_all.deb
 Size: 38056418
 MD5sum: 84529c04673ebe58208b4d0820853e54
 SHA1: 1c5df6bd354395edac88e136d9503ee8c92d60f3
 SHA256: 25270ed4f113423754c4fab03e48d13396896d98f087e8980e11e61bd97ff711
 Description: Continuous integration system written in Java
  Jenkins is an extensible continuous engine written in Java.
 Homepage: https://jenkins-ci.org/
 
 Note despite this 1.404, Jenkins actually displays 1.407 in its footer
Reporter: Jay Levitt
Priority: Critical

 I am setting up Jenkins for the first time. I've successfully gone into the 
 configure system screen before, because I was able to set up matrix user 
 permissions as outlined in the Standard Security guide. I wanted to add an 
 environment variable to set the time, but now I'm unable, because the page 
 load never completes. I'm new to java, but happy to troubleshoot and try 
 things if you tell me what logs to look at. This is NOT running under TomCat.

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

[JIRA] (JENKINS-12421) Add pre-send step to email-ext that can modify the mail message object

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

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

terryl westerhold commented on JENKINS-12421:
-

Yes, that is what I was thinking.  I am curious to know how you are thinking 
you will approach this issue though.  Having a feature that specifically 
addressed the claim issue would be great, but I really think the more 
elaborate solution I mentioned in my initial post would be much more 
beneficial.  Giving the option to run a pre-send script after the message was 
fully built would give me the ability to fix this issue, and the potential to 
do many other things with the MimeMessage before it was sent.

 Add pre-send step to email-ext that can modify the mail message object
 --

 Key: JENKINS-12421
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12421
 Project: Jenkins
  Issue Type: New Feature
  Components: claim, email-ext
Affects Versions: current
 Environment: All
Reporter: terryl westerhold
Assignee: Slide-O-Mix
  Labels: claim, email-ext, feature, groovy, jenkins, plugin, 
 script

 When the Email-Ext plugin is used in conjunction with the Claim plugin there 
 is no way to configure a project's email options to only send to the one who 
 has claimed it.  This results in every person on a team receiving emails for 
 a build they did not break, turning Jenkins emails into something annoying 
 instead of something useful.  For someone who knew the code this would be a 
 pretty easy feature to add.  And while this would be a good feature, I think 
 a more elaborate solution that would allow Email-ext plugin users to 
 access/modify all parts of the email message (including who the message is 
 being sent to) would be more useful in the long run.  Giving users access to 
 all parts of the email message and the option to run a Groovy script after 
 the email has been built, but before the email has been sent would satisfy 
 this feature request and would make the Email-Ext plugin much more versatile.

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

[JIRA] (JENKINS-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-

Component/s: memegen
 (was: jenkins-plugin-runtime)

 Template variables are permanently overwritten on first use
 ---

 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: memegen
Affects Versions: current
 Environment: Should happen on all systems and versions.
Reporter: Jon Cairns
Assignee: Jon Cairns
  Labels: jenkins, meme

 Meme configurations that include template variables such as ${project} will 
 be overwritten with the actual name of the project that first uses that Meme, 
 as the Meme object is not copied/cloned, and it is automatically saved. The 
 fix is to create a copy of the object and use that for the Meme generation.

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

[JIRA] (JENKINS-12421) Add pre-send step to email-ext that can modify the mail message object

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

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

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

I am planning on adding the groovy feature, I was just wondering where you 
might want to configure it. If only at the project level (not at the global 
level and not at the trigger level) it makes it a bit easier :-)

 Add pre-send step to email-ext that can modify the mail message object
 --

 Key: JENKINS-12421
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12421
 Project: Jenkins
  Issue Type: New Feature
  Components: claim, email-ext
Affects Versions: current
 Environment: All
Reporter: terryl westerhold
Assignee: Slide-O-Mix
  Labels: claim, email-ext, feature, groovy, jenkins, plugin, 
 script

 When the Email-Ext plugin is used in conjunction with the Claim plugin there 
 is no way to configure a project's email options to only send to the one who 
 has claimed it.  This results in every person on a team receiving emails for 
 a build they did not break, turning Jenkins emails into something annoying 
 instead of something useful.  For someone who knew the code this would be a 
 pretty easy feature to add.  And while this would be a good feature, I think 
 a more elaborate solution that would allow Email-ext plugin users to 
 access/modify all parts of the email message (including who the message is 
 being sent to) would be more useful in the long run.  Giving users access to 
 all parts of the email message and the option to run a Groovy script after 
 the email has been built, but before the email has been sent would satisfy 
 this feature request and would make the Email-Ext plugin much more versatile.

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

[JIRA] (JENKINS-13812) Include a functionality that lets the user see only Failed tests, or toggle between different views for TAP Results

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

Bruno P. Kinoshita created JENKINS-13812:


 Summary: Include a functionality that lets the user see only 
Failed tests, or toggle between different views for TAP Results
 Key: JENKINS-13812
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13812
 Project: Jenkins
  Issue Type: Improvement
  Components: tap
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita


From e-mail: 

Can we have functionality to see all the FAILs at the top of the TAP output? 
We are less concerned with all the PASSes. From my perspective, having a way 
to toggle between the full TAP output and FAILs only would be ideal.
 
This becomes important when you find you are paging through many screens of 
TAP results!

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

[JIRA] (JENKINS-850) search box should match non-casesensitively

[radek.chr...@gooddata.com (JIRA)]

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

Radek Chromy commented on JENKINS-850:
--

It seems to be platform/environment depended:
Jenkins ver. 1.464
Linux Ubuntu 12.04, Chromium 18.0.1025.151, search is case *insensitive*.
Mac OS X 10.7.3 a Chrome Version 19.0.1084.46, search is case *sensitive*.


 search box should match non-casesensitively
 ---

 Key: JENKINS-850
 URL: https://issues.jenkins-ci.org/browse/JENKINS-850
 Project: Jenkins
  Issue Type: Improvement
  Components: www
Affects Versions: current
 Environment: Platform: All, OS: All
Reporter: gradopado
Assignee: dogfood

 The search box would be even more useful if it would match text 
 non-casesensitively.

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

[JIRA] (JENKINS-13813) NullPointer after upgrading to 1.6

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

lshatzer created JENKINS-13813:
--

 Summary: NullPointer after upgrading to 1.6
 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: jeffg2one
Priority: Critical


After upgrading to 1.6, when my Grails jobs run, I get a NPE:
{code}
java.lang.NullPointerException
at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{code}

I save my job after opening it up and saving it without changing, it now works. 
The config file now has an empty: useWrapper element. Your plugin should 
probably handle it missing without having to resave all grails jobs.

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

[JIRA] (JENKINS-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Work on JENKINS-13809 started by Jon Cairns.

 Template variables are permanently overwritten on first use
 ---

 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: memegen
Affects Versions: current
 Environment: Should happen on all systems and versions of Jenkins.
Reporter: Jon Cairns
Assignee: Jon Cairns
  Labels: jenkins, meme

 Meme configurations that include template variables such as ${project} will 
 be overwritten with the actual name of the project that first uses that Meme, 
 as the Meme object is not copied/cloned, and it is automatically saved. The 
 fix is to create a copy of the object and use that for the Meme generation.

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

[JIRA] (JENKINS-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-

Environment: Should happen on all systems and versions of Jenkins.  (was: 
Should happen on all systems and versions.)

 Template variables are permanently overwritten on first use
 ---

 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: memegen
Affects Versions: current
 Environment: Should happen on all systems and versions of Jenkins.
Reporter: Jon Cairns
Assignee: Jon Cairns
  Labels: jenkins, meme

 Meme configurations that include template variables such as ${project} will 
 be overwritten with the actual name of the project that first uses that Meme, 
 as the Meme object is not copied/cloned, and it is automatically saved. The 
 fix is to create a copy of the object and use that for the Meme generation.

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

[JIRA] (JENKINS-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-


This is present in all versions up to 0.3.2.

 Template variables are permanently overwritten on first use
 ---

 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: memegen
Affects Versions: current
 Environment: Should happen on all systems and versions of Jenkins.
Reporter: Jon Cairns
Assignee: Jon Cairns
  Labels: jenkins, meme

 Meme configurations that include template variables such as ${project} will 
 be overwritten with the actual name of the project that first uses that Meme, 
 as the Meme object is not copied/cloned, and it is automatically saved. The 
 fix is to create a copy of the object and use that for the Meme generation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 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-tabpanelfocusedCommentId=162889#comment-162889
 ] 

Amir Isfy commented on JENKINS-13227:
-

I am getting the info on our CVS setup from the IT. In the meantime I can 
confirm that the projects that are polling the Head are fine, detecting changes 
and posting the changes on the web interface.

 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

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

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

Amir Isfy commented on JENKINS-13227:
-

We're using CVSNT 2.5.03
We authenticate using pserver


 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-8744) Maven cannot run with JDK1.5 anymore

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

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

Bruno Medeiros commented on JENKINS-8744:
-

Same error here, on Jenkins 1.463:

{code}
===[JENKINS REMOTING CAPACITY]===channel started
log4j:WARN No appenders could be found for logger 
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
channel stopped
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven 
[/var/lib/jenkins/tools/Sun_JDK_1.5/bin/java, -cp, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar:/var/lib/jenkins/tools/Maven_2/boot/classworlds-1.1.jar,
 hudson.maven.agent.Main, /var/lib/jenkins/tools/Maven_2, 
/var/cache/jenkins/war/WEB-INF/lib/remoting-2.13.jar, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.2.jar, 
59378, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar] 
failed
at hudson.remoting.Channel.call(Channel.java:655)
at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
at 
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:791)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
at hudson.model.Run.run(Run.java:1434)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: java.lang.ClassFormatError: Failed to load 
com.google.common.collect.ImmutableSet
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at hudson.security.PermissionScope.init(PermissionScope.java:70)
at hudson.security.PermissionScope.clinit(PermissionScope.java:95)
at hudson.security.Permission.init(Permission.java:179)
at hudson.security.Permission.clinit(Permission.java:292)
at hudson.model.Run.clinit(Run.java:2038)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:74)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:53)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class 
file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:152)
... 20 more
Finished: FAILURE
/pre
{code}

 Maven cannot run with JDK1.5 anymore
 

 Key: JENKINS-8744
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8744
 Project: Jenkins
  Issue Type: Bug
  Components: maven2
Reporter: Rainer Weinhold

 Since an update to jenkins 1.395 the maven projects running with an JDK 1.5 
 arent working anymore. 
 The error Bad version number in .class file looks like something got 
 compiled with a newer java version. This error happens on a slave with maven 
 2.0.11 and oracle-jdk 1.5.21. 
 - When i reconfigure the project to oracle-jdk 1.6.20 it works.
 - It also works with java 1.5 when executed directly on den shell. 
 - The only thing different there is the magic agent stuff.
 So i extracted the jars : maven-interceptor, maven-agent, slave.jar, 
 classworlds. Non of which there seems to be a newer .class version number. 
 Any ideas which files could cause the problem? Pretty sure this is a jenkins 
 issue, otherwise maven wouldn't compile it directly on the build system.
 LOG:
 {noformat}
 At revision 56650
 no change for http://.../trunk since the previous build
 Found mavenVersion 2.0.11 from file 
 

[JIRA] (JENKINS-13814) java.lang.OutOfMemoryError exception when getting the remote log

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

James Gustafson created JENKINS-13814:
-

 Summary: java.lang.OutOfMemoryError exception when getting the 
remote log
 Key: JENKINS-13814
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13814
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
 Environment: Jenkins 1.464 on Windows 7 64-bit, 12GB RAM; CVS Plug-in 
2.4-SNAPSHOT
Reporter: James Gustafson


We are getting a java.lang.OutOfMemoryError exception when getting the remote 
log.

{quote}
Started by an SCM change
Building in workspace C:\x\workspace\project_name_here
cvs checkout -r BRANCH_NAME_HERE -D 16 May 2012 23:27:38 -0700 -d path\projects 
path/projects
cvs checkout: Updating path\projects
cvs checkout: Updating path\projects/dir1
cvs checkout: Updating path\projects/dir2/dirA
... (about 7,224 directories) ...
cvs checkout: Updating path\projects/dirN
cvs rlog: Logging path\projects
... (about 7,224 directories) ...
cvs rlog: Logging path\projects/dirN
FATAL: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.lang.StringCoding$StringDecoder.decode(Unknown Source)
at java.lang.StringCoding.decode(Unknown Source)
at java.lang.StringCoding.decode(Unknown Source)
at java.lang.String.init(Unknown Source)
at java.io.ByteArrayOutputStream.toString(Unknown Source)
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:540)
at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:415)
at hudson.scm.CVSSCM.checkout(CVSSCM.java:825)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{quote}


Some notes:
- The path/ and path\ comes from the Remote Name/Local Name settings 
solution from Issue JENKINS-13264
- We are using Jenkins 1.464 with the 2.4-SNAPSHOT version of the CVS plugin, 
but may not have been caused by this specific version
- The arguments setting in the jenkins.xml file currently has -Xms1024m 
(anything larger and Jenkins service won't start)
- The CVS module has many legacy projects spread out, and thus, contains more 
than 7,000 directories and many more files
- Things had worked with the 1.6 plug-in  CVSNT client, but it also 
occasionally timed out getting the changelog, hence our testing of the 2.x 
plug-ins


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

[JIRA] (JENKINS-13735) Jenkins starts wrong slave for job restricted to specific one

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

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

jsiirola commented on JENKINS-13735:


I am also seeing this problem after upgrading from 1.459 - 1.464 (running 
Winstone under Linux).  I do not have the vSphere plugin installed.  In my 
case, the problem is being exacerbated by one of the build slaves being down 
for maintenance.  This has led to jobs stacking up in the queue, which in turn 
has led to Jenkins starting every slave in the farm.

 Jenkins starts wrong slave for job restricted to specific one
 -

 Key: JENKINS-13735
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13735
 Project: Jenkins
  Issue Type: Bug
  Components: master-slave, slave-setup, vsphere-cloud
Affects Versions: current
 Environment: Jenkins 1.463 under Tomcat6 on Linux (SLES 11), Windows 
 XP slave VMs controlled via vSphere Cloud plugin
Reporter: Marco Lehnort
Assignee: Kohsuke Kawaguchi
  Labels: slave

 I'm using the following setup:
 - WinXP slaves A,B,C
 - jobs jA, jB, jC, tied to slaves A,B,C respectively using Restrict where 
 this job can run
 Assume all slaves are disconnected and powered off, no builds are queued.
 When starting a build manually, say jC, the following will happen:
 - job jC will be scheduled and also displayed accordingly in the build queue
 - tooltip will say it's waiting because slave C is offline
 - next, slave A is powered on by Jenkins and connection is established
 - jC will not be started, Jenkins seems to honor the restriction correctly
 - after some idle time, Jenkins realizes the slave is idle and causes shut 
 down
 - then, same procedure happens with slave B
 - on occasion, next one is slave A again
 - finally (on good luck?) slave C happens to be started
 - jC is executed
 It is possible that jC is waiting for hours (indefinitely?), because the 
 required
 slave is not powered on. I also observed this behaviour using a time-trigger
 instead of manual trigger, so I assume it is independent of the type of 
 trigger.
 Occasionally it also happens that the correct slave is powered up right away,
 but that seems to happen by chance. The concrete pattern is not obvious to me.
 Note that the component selection above is just my best guess.
 Cheers, Marco

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

[JIRA] (JENKINS-12972) Add option to run 'git bisect' to find which commit added new bugs

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

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

bnovc commented on JENKINS-12972:
-

{{git blame}} would be faster, but you would often not get correct results. 
This only works if the problem you're trying to detect was caused by the last 
edit to the line the problem was exposed.

I would really like to see {{git bisect}} offered as part of a normal build 
with the git plugin. That way I would immediately know who broke the build 
definitively. This would save significant time in triaging, as the person 
responsible could be notified automatically.

 Add option to run 'git bisect' to find which commit added new bugs 
 ---

 Key: JENKINS-12972
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12972
 Project: Jenkins
  Issue Type: New Feature
  Components: analysis-core, core, findbugs, git
Reporter: Eyal Edri
Priority: Minor

 Today, when you run find-bugs plug-in triggered by a git commit, you can't 
 know exactly which commit added those bugs.
 It becomes especially difficult to know when a high volume of commits is 
 pushed at once.
 find-bugs plug-in could have a new option to tick in the 'advanced section',
 which will do a 'git bisect' on the git commits that caused a new bug and 
 display/email to commiter who did it.
 that would simply and automate the process of finding who wrote the bug.

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

[JIRA] (JENKINS-13815) scm-sync-configuration raises unexpectedError() loading job configuration in IE8

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

jsiirola created JENKINS-13815:
--

 Summary: scm-sync-configuration raises unexpectedError() loading 
job configuration in IE8
 Key: JENKINS-13815
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13815
 Project: Jenkins
  Issue Type: Bug
  Components: scm-sync-configuration
 Environment: Jenkins 1.464, scm-sync-configuration 0.0.5, IE8
Reporter: jsiirola
Assignee: Frédéric Camblor


The scm-sync-configuration plugin raises the following alert when loading a job 
configuration using IE8:
{noformat}
Something went wrong with the scm-sync-configuration plugin !
Please report a JIRA with as much informations as possible (browser, os, 
current url, error message etc.).
Error message : Cannot retrieve target form on current page !
{noformat}
This only happens in IE8 (Firefox throws no warning), and if you are accessing 
the job configuration through a View other then the default (All) view.  
Accessing the job through the All view does not raise the error.  For 
example, the following does not raise an error:
{noformat}
http://localhost:8080/job/my_test/configure
{noformat}
But this URL does (but only in IE8, not Firefox):
{noformat}
http://localhost:8080/view/Tests/job/my_test/configure
{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

From Groovy script, SCM polling reports incorrect info if job makes its own checkins

[Joel S]

I have a bunch of interrelated jobs that do Maven releases.  For various
reasons, they're not using the Jenkins release plugin, but rather invoke mvn
release:prepare release:perform as one of a sequence of steps.  I have all
the jobs linked together using build triggers, so if you run one of these
release jobs, it knows which others depend on it and need to be run
afterward.  Before doing the release, each job updates its pom.xml with the
latest versions released by the previous upstream jobs.

So far so good, that all works perfectly.  But, I wanted to automate one
more piece.  Currently, you have to know which parts of the project have
been updated since the last release, and manually start those releases.  It
seems like all the information is available to Jenkins to figure that out
for me, though.  It knows when each job ran, it has hooks to talk to the SCM
to find out if new changes have been checked in, so a simple Groovy script
should suffice.  But there's a catch.

Maybe this would work with other SCMs, but I'm using svn, and here's what
happens.  When I run one of my release jobs, Jenkins first does an SCM
update to pull down all the changes.  Then it does the release, which checks
in two changes to the pom.xml file.  The state of the workspace has now
changed - the SCM revision that Jenkins originally pulled down isn't the
latest any more, it's been bumped twice.  The workspace knows this, but I
think Jenkins doesn't.  The svn plugin keeps a file around called
revision.txt, and this file appears to be a cache of what revision the
workspace is at.  So, in my Groovy script, when I ask Jenkins whether that
job has SCM changes, and therefore needs to be run, Jenkins always answers
yes.  This is because it's looking at revision.txt to figure out if the
workspace needs updating, and revision.txt is out of date -- it still thinks
the workspace doesn't have the two changes committed during the release.  My
Groovy script looks like this:

job = passed to my function
def latestBuild = job.getLastCompletedBuild();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
def listener = new hudson.model.StreamBuildListener(baos);
def launcher = new hudson.Launcher.LocalLauncher(listener);
def scmrev = job.scm.calcRevisionsFromBuild(latestBuild, launcher,
listener);
def pollingResult = job.scm.compareRemoteRevisionWith(job, launcher,
job.workspace, listener, scmrev);
return pollingResult.hasChanges();

I've tried to force the workspace to do a checkout, to update revision.txt,
but ironically, that takes the workspace backward in time.  Here's the
script I'm using:

job = passed to my function
def latestBuild = job.getLastCompletedBuild();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
def listener = new hudson.model.StreamBuildListener(baos);
def launcher = new hudson.Launcher.LocalLauncher(listener);
job.scm.checkout(latestBuild, launcher, job.workspace, listener,
File.createTempFile(tempcheckout, txt));

When it runs, it decides for some reason to refresh the workspace to the
state described in revision.txt, rather than the state in the depot.

So, I'm hoping someone can tell me that I'm just looking at this the wrong
way, and there's a simple thing I can do to force revision.txt to get
updated after the mvn release finishes.  Or maybe there's some other way to
invoke checkout so that it updates revision.txt to match the workspace,
rather than the other way around.  Thanks.

-Joel


--
View this message in context: 
http://jenkins.361315.n4.nabble.com/From-Groovy-script-SCM-polling-reports-incorrect-info-if-job-makes-its-own-checkins-tp4628884.html
Sent from the Jenkins issues mailing list archive at Nabble.com.

[JIRA] (JENKINS-13816) Refactor hundson.MarkupText to allow replacing entire HTML body

[dbl...@dblock.org (JIRA)]

Daniel Doubrovkine created JENKINS-13816:


 Summary: Refactor hundson.MarkupText to allow replacing entire 
HTML body
 Key: JENKINS-13816
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13816
 Project: Jenkins
  Issue Type: Improvement
  Components: core
Reporter: Daniel Doubrovkine
Priority: Minor


The implementation of AnsiColor is quite hacky. It needs to replace the entire 
body of text with html (translates ansi codes that can appear anywhere inside 
the text to html). Unfortunately MarkupText only lets you markup the text by 
inserting tags in different locations, which is not practical at all since we 
need to delete existing text and insert tags all over the place.

I'd like to see MarkupText refactored to allow complete replacement of the data 
with unencoded html. For starters, maybe a clearText() could get the job done? 
Generally, markuptext is trying to be too smart about markup. 

Another option could be an extension point that lets me replace the text stream 
with html (unencoded).

Refactor core/src/main/java/hudson/MarkupText.java
https://github.com/dblock/jenkins-ansicolor-plugin

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

[JIRA] (JENKINS-13817) Jenkins Displays Accurev Password in Logs

[timothy.johns...@kronos.com (JIRA)]

tim johnston created JENKINS-13817:
--

 Summary: Jenkins Displays Accurev Password in Logs
 Key: JENKINS-13817
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13817
 Project: Jenkins
  Issue Type: Bug
  Components: accurev
Affects Versions: current
 Environment: windows
Reporter: tim johnston
Assignee: Scott Tatum


When an accurev command fails, it displays the users' password in plain text. 
You can see below that the password is properly obscured (with asterisks) when 
the authentication takes place. 

Unfortunately, the password is actually displayed in the fatal network error 
line. Note that I manually changed it to  when I pasted the text into this 
bug report.

Error text:

Started by user anonymous
Building remotely on TestReport in workspace 
D:\jenkins-slave\workspace\Test_Report_06_04_00_Budgeting_kvh223_WFOP_Macys_ora
Purging workspace...
Workspace purged.
Setting ACCUREV_HOME to D:\jenkins-slave\workspace
Authenticating with Accurev server...
[Test_Report_06_04_00_Budgeting_kvh223_WFOP_Macys_ora] $ C:\Program Files 
(x86)\AccuRev\bin\accurev.exe login -H engaccurev:5051 tim.johnston 
FATAL: network error - Can't connect to engaccurev.kronos.com for accurev: The 
operation completed successfully. 
Attempt to contact AccuRev server on engaccurev port 5051 failed.
Giving up.
AccuRev Error: 1

FATAL: login (C:\Program Files (x86)\AccuRev\bin\accurev.exe login -H 
engaccurev:5051 tim.johnston ^^^) failed with exit code 1
Archiving artifacts
Recording test results
Notifying upstream projects of job completion
Finished: FAILURE

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

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

[pradeep.pa...@ericsson.com (JIRA)]

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

Pradeep Patil commented on JENKINS-13227:
-

I have been following this issue and I am also having similar problems .. in my 
case when I upgraded the plugin a lot of my builds started getting kicked off 
regularly like every hour .. and the version number are getting tagged every 
time a new build is kicked off which is supposed to happen only when new 
changes are found. so basically the builds are happening even when there are no 
changes and version tags are getting incremented.


This is the cvs polling log found in every build kicked every hour .. 

Started on May 17, 2012 3:00:33 PM
cvs rlog: Logging lscpproxy-java
cvs rlog: Logging lscpproxy-java/bin
cvs rlog: Logging lscpproxy-java/build
cvs rlog: Logging lscpproxy-java/conf
cvs rlog: Logging lscpproxy-java/lib
cvs rlog: Logging lscpproxy-java/mib
cvs rlog: Logging lscpproxy-java/scripts
cvs rlog: Logging lscpproxy-java/src
cvs rlog: Logging lscpproxy-java/src/com
cvs rlog: Logging lscpproxy-java/src/com/n2bb
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/C1Udp
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/exceptions
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/injection
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/monitoring
cvs rlog: Logging lscpproxy-java/src/main
cvs rlog: Logging lscpproxy-java/src/main/xml
cvs rlog: Logging lscpproxy-java/test
cvs rlog: Logging lscpproxy-java/test/scripts
cvs rlog: Logging lscpproxy-java/test/src
cvs rlog: Logging lscpproxy-java/test/src/com
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http/testServer
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/lsc
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/rtsp
Done. Took 0.32 sec
Changes found


I also get a lot of rlog errors like this :

java.lang.RuntimeException: Error while trying to run CVS rlog
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:523)
at hudson.scm.CVSSCM.calculateRepositoryState(CVSSCM.java:459)
at hudson.scm.CVSSCM.compareRemoteRevisionWith(CVSSCM.java:320)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject.poll(AbstractProject.java:1346)
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:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Can someone help ? I have tried to delte the projects and recreate them on 
jenkins and its not helping .. they are still getting triggered every hour .. 

 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 
 

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

[guillaume.bilod...@gmail.com (JIRA)]

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

Guillaume Bilodeau commented on JENKINS-13227:
--

Client: Concurrent Versions System (CVSNT) 2.0.4 (client/server)
Server: Concurrent Versions System (CVS) 1.11.22-FCDQ_LEGO-2.2 (client/server)
Authenticating with pserver

(yes the server version appears to be customized but I've been guaranteed that 
the original sources were compiled and only the binary name has been changed)

I confirm that polling detects changes when run against the CVS head.

Thanks!


 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

Re: [JIRA] Updated: (JENKINS-2337) CVSTag plugin does not work for Branches - only HEAD

[yjl]

CVS tagging plugin is not working fro CVS plugin 2.0 or later. When will it
be fixed?

--
View this message in context: 
http://jenkins.361315.n4.nabble.com/JIRA-Updated-JENKINS-2337-CVSTag-plugin-does-not-work-for-Branches-only-HEAD-tp3497378p4628893.html
Sent from the Jenkins issues mailing list archive at Nabble.com.

[JIRA] (JENKINS-13818) Jelly f:combobox controls not triggering 'change' events

[char...@talibard.com (JIRA)]

Charles Talibard created JENKINS-13818:
--

 Summary: Jelly f:combobox controls not triggering 'change' events
 Key: JENKINS-13818
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13818
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Charles Talibard
Priority: Minor


When using jelly f:combobox controls, if a user selects a valid value from the 
list either using the keyboard or mouse, the browser doesn't fire either 
old-style onchange() or new DOM 2 change events. This means that the validation 
doCheckXyz() method isn't called for the new value and subsequent comboboxes 
whose doFillXyzItems() depend on the new value don't fire.

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

[JIRA] (JENKINS-13818) Jelly f:combobox controls not triggering 'change' events

[char...@talibard.com (JIRA)]

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

Charles Talibard updated JENKINS-13818:
---

Labels: gui jelly jenkins  (was: gui jenkins)

 Jelly f:combobox controls not triggering 'change' events
 

 Key: JENKINS-13818
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13818
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Charles Talibard
Priority: Minor
  Labels: gui, jelly, jenkins

 When using jelly f:combobox controls, if a user selects a valid value from 
 the list either using the keyboard or mouse, the browser doesn't fire either 
 old-style onchange() or new DOM 2 change events. This means that the 
 validation doCheckXyz() method isn't called for the new value and subsequent 
 comboboxes whose doFillXyzItems() depend on the new value don't fire.

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

[JIRA] (JENKINS-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

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

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

wgracelee commented on JENKINS-13617:
-

We're getting this error at least once per day after we upgraded to 1.463. In 
its previous version, 1.456, we hardly saw it. The underneath os is Centos 5.5, 
64bit.

 64-bit java.lang.OutOfMemoryError: PermGen space
 

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

 Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
 space about once a day with light load. Our 32-bit Jenkins has never had this 
 problem and no special settings. Memory leak?
 Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 at java.lang.Throwable.getStackTraceElement(Native Method)
 at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTrace(Throwable.java:516)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
 at 
 net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
 at 
 org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at 
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
 at 
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
 at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java: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:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
 SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
 failed
 java.lang.OutOfMemoryError: PermGen space

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 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

[pradeep.pa...@ericsson.com (JIRA)]

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

Pradeep Patil commented on JENKINS-13227:
-

I tested it with the new plugin (2.4-SNAPSHOT (private-05/15/2012 
16:22-hudson)). In The first project that was kicked off after polling for 
changes it went ahead and started checking out the entire cvs repository.

Here is sample cvs command ..
Started by an SCM change
Building on master in workspace /buildpool/jenkins/jobs/logClient-HEAD/workspace
cvs update -d -P -r HEAD -D 17 May 2012 17:22:54 -0400 workspace 
cvs update: Updating ...

This happened while testing with a new project on Jenkins and also on a old 
project on Jenkins. Both of the project were pointing to HEAD.

 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

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

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

wgracelee commented on JENKINS-13617:
-

And our Jenkins is being run as:
java -XX:NewSize=256m -XX:MaxNewSize=256m -XX:SurvivorRatio=8 
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled 
-XX:+CMSClassUnloadingEnabled -Xms... -Xmx... -jar ...

 64-bit java.lang.OutOfMemoryError: PermGen space
 

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

 Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
 space about once a day with light load. Our 32-bit Jenkins has never had this 
 problem and no special settings. Memory leak?
 Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 at java.lang.Throwable.getStackTraceElement(Native Method)
 at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTrace(Throwable.java:516)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
 at 
 net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
 at 
 org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at 
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
 at 
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
 at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java: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:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
 SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
 failed
 java.lang.OutOfMemoryError: PermGen space

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

[JIRA] (JENKINS-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

[ever...@free.fr (JIRA)]

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

evernat commented on JENKINS-13617:
---

and you have not set MaxPermSize?


 64-bit java.lang.OutOfMemoryError: PermGen space
 

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

 Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
 space about once a day with light load. Our 32-bit Jenkins has never had this 
 problem and no special settings. Memory leak?
 Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 at java.lang.Throwable.getStackTraceElement(Native Method)
 at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTrace(Throwable.java:516)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
 at 
 net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
 at 
 org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at 
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
 at 
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
 at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java: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:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
 SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
 failed
 java.lang.OutOfMemoryError: PermGen space

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

[JIRA] (JENKINS-6565) Hudson stuck on inexistent job

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

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

Kyle Leinen commented on JENKINS-6565:
--

I am also seeing this.  The job cannot be cleared/cancelled without restarting 
Jenkins completely, which is a pain.

 Hudson stuck on inexistent job
 --

 Key: JENKINS-6565
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6565
 Project: Jenkins
  Issue Type: Bug
  Components: locks-and-latches
Reporter: rombert
Assignee: stephenconnolly
Priority: Blocker
 Attachments: hudon-stuck-system-information.txt, 
 hudson-stuck-enabled-plugins.txt, hudson-stuck-executors.png, 
 hudson-stuck-home-page-queue.png, hudson-stuck-thread-dump.txt


 After a couple of days, Hudson seems to see a a 'phantom' build queued , 
 which does not execute at all, but it blocks the next job from running. The 
 currently executing build is 'Collectors' and the stuck build is 
 'SportsEngine-Collection' . The stuck build is a Maven2 build, using the 
 locks-and-latches plugin, polling SVN every minute.

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

[JIRA] (JENKINS-13815) scm-sync-configuration raises unexpectedError() loading job configuration in IE8

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

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

Frédéric Camblor commented on JENKINS-13815:


Thanks for your detailed feedback ! :)

Will try to fix this ASAP !

 scm-sync-configuration raises unexpectedError() loading job configuration in 
 IE8
 

 Key: JENKINS-13815
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13815
 Project: Jenkins
  Issue Type: Bug
  Components: scm-sync-configuration
 Environment: Jenkins 1.464, scm-sync-configuration 0.0.5, IE8
Reporter: jsiirola
Assignee: Frédéric Camblor

 The scm-sync-configuration plugin raises the following alert when loading a 
 job configuration using IE8:
 {noformat}
 Something went wrong with the scm-sync-configuration plugin !
 Please report a JIRA with as much informations as possible (browser, os, 
 current url, error message etc.).
 Error message : Cannot retrieve target form on current page !
 {noformat}
 This only happens in IE8 (Firefox throws no warning), and if you are 
 accessing the job configuration through a View other then the default (All) 
 view.  Accessing the job through the All view does not raise the error.  
 For example, the following does not raise an error:
 {noformat}
 http://localhost:8080/job/my_test/configure
 {noformat}
 But this URL does (but only in IE8, not Firefox):
 {noformat}
 http://localhost:8080/view/Tests/job/my_test/configure
 {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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

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

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

wgracelee commented on JENKINS-13617:
-

Nop. I'll set it to 512m to see how it turned out.

 64-bit java.lang.OutOfMemoryError: PermGen space
 

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

 Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
 space about once a day with light load. Our 32-bit Jenkins has never had this 
 problem and no special settings. Memory leak?
 Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 at java.lang.Throwable.getStackTraceElement(Native Method)
 at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
 at java.lang.Throwable.printStackTrace(Throwable.java:516)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
 at 
 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
 at 
 net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
 at 
 org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
 at 
 hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
 at 
 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
 at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
 at 
 hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
 at 
 hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
 at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
 at winstone.FilterConfiguration.execute(FilterConfiguration.java: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:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
 WARNING: Untrapped Error in Servlet
 java.lang.OutOfMemoryError: PermGen space
 Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
 SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
 failed
 java.lang.OutOfMemoryError: PermGen space

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

[JIRA] (JENKINS-13813) NullPointer after upgrading to 1.6

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

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

kiy0taka reassigned JENKINS-13813:
--

Assignee: kiy0taka  (was: jeffg2one)

 NullPointer after upgrading to 1.6
 --

 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: kiy0taka
Priority: Critical

 After upgrading to 1.6, when my Grails jobs run, I get a NPE:
 {code}
 java.lang.NullPointerException
   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
   at hudson.model.Build$RunnerImpl.build(Build.java:178)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
   at hudson.model.Run.run(Run.java:1434)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:239)
 {code}
 I save my job after opening it up and saving it without changing, it now 
 works. The config file now has an empty: useWrapper element. Your plugin 
 should probably handle it missing without having to resave all grails jobs.

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

[JIRA] (JENKINS-13813) NullPointer after upgrading to 1.6

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

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

kiy0taka commented on JENKINS-13813:


If you want to fix this problem now, please run script via Script Console 
(http://yourjenkins/script).
{code}
import hudson.model.*
import com.g2one.hudson.grails.GrailsBuilder

Hudson.instance.items.each { item -
item.builders.findAll { it in GrailsBuilder  it.useWrapper == null } 
.each {
it.useWrapper = false
item.save()
}
}
{code}

 NullPointer after upgrading to 1.6
 --

 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: kiy0taka
Priority: Critical

 After upgrading to 1.6, when my Grails jobs run, I get a NPE:
 {code}
 java.lang.NullPointerException
   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
   at hudson.model.Build$RunnerImpl.build(Build.java:178)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
   at hudson.model.Run.run(Run.java:1434)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:239)
 {code}
 I save my job after opening it up and saving it without changing, it now 
 works. The config file now has an empty: useWrapper element. Your plugin 
 should probably handle it missing without having to resave all grails jobs.

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

[JIRA] (JENKINS-13813) NullPointer after upgrading to 1.6

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

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

SCM/JIRA link daemon commented on JENKINS-13813:


Code changed in jenkins
User: kiy0taka
Path:
 src/main/java/com/g2one/hudson/grails/GrailsBuilder.java
http://jenkins-ci.org/commit/grails-plugin/9236327cd1096b6ca821270fdd7ee931a44c8efb
Log:
  fix bug. refs JENKINS-13813






 NullPointer after upgrading to 1.6
 --

 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: kiy0taka
Priority: Critical

 After upgrading to 1.6, when my Grails jobs run, I get a NPE:
 {code}
 java.lang.NullPointerException
   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
   at hudson.model.Build$RunnerImpl.build(Build.java:178)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
   at hudson.model.Run.run(Run.java:1434)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:239)
 {code}
 I save my job after opening it up and saving it without changing, it now 
 works. The config file now has an empty: useWrapper element. Your plugin 
 should probably handle it missing without having to resave all grails jobs.

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

[JIRA] (JENKINS-13813) NullPointer after upgrading to 1.6

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

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

kiy0taka resolved JENKINS-13813.


Resolution: Fixed

 NullPointer after upgrading to 1.6
 --

 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: kiy0taka
Priority: Critical

 After upgrading to 1.6, when my Grails jobs run, I get a NPE:
 {code}
 java.lang.NullPointerException
   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
   at hudson.model.Build$RunnerImpl.build(Build.java:178)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
   at hudson.model.Run.run(Run.java:1434)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:239)
 {code}
 I save my job after opening it up and saving it without changing, it now 
 works. The config file now has an empty: useWrapper element. Your plugin 
 should probably handle it missing without having to resave all grails jobs.

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

[JIRA] (JENKINS-8744) Maven cannot run with JDK1.5 anymore

[s.sog...@gmail.com (JIRA)]

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

sogabe commented on JENKINS-8744:
-

@Bruno Updating to 1.464 will help you. See JENKINS-13659 

 Maven cannot run with JDK1.5 anymore
 

 Key: JENKINS-8744
 URL: https://issues.jenkins-ci.org/browse/JENKINS-8744
 Project: Jenkins
  Issue Type: Bug
  Components: maven2
Reporter: Rainer Weinhold

 Since an update to jenkins 1.395 the maven projects running with an JDK 1.5 
 arent working anymore. 
 The error Bad version number in .class file looks like something got 
 compiled with a newer java version. This error happens on a slave with maven 
 2.0.11 and oracle-jdk 1.5.21. 
 - When i reconfigure the project to oracle-jdk 1.6.20 it works.
 - It also works with java 1.5 when executed directly on den shell. 
 - The only thing different there is the magic agent stuff.
 So i extracted the jars : maven-interceptor, maven-agent, slave.jar, 
 classworlds. Non of which there seems to be a newer .class version number. 
 Any ideas which files could cause the problem? Pretty sure this is a jenkins 
 issue, otherwise maven wouldn't compile it directly on the build system.
 LOG:
 {noformat}
 At revision 56650
 no change for http://.../trunk since the previous build
 Found mavenVersion 2.0.11 from file 
 jar:file:/srv/hudson/tools/maven-2.0.x/lib/maven-2.0.11-uber.jar!/META-INF/maven/org.apache.maven/maven-core/pom.properties
 No emails were triggered.
 Parsing POMs
 [maven-versioninfo-plugin] $ /srv/hudson/tools/Java-1.5.x/bin/java -Xmx512m 
 -Xms64m -XX:PermSize=64m -XX:MaxPermSize=128m -cp 
 /srv/hudson/maven-agent.jar:/srv/hudson/classworlds.jar 
 hudson.maven.agent.Main /srv/hudson/tools/maven-2.0.x /srv/hudson/slave.jar 
 /srv/hudson/maven-interceptor.jar 44373
 ===[HUDSON REMOTING CAPACITY]===���channel started
 channel stopped
 ERROR: POMs konnten nicht geparst werden
 java.io.IOException: Remote call on Channel to Maven 
 [/srv/hudson/tools/Java-1.5.x/bin/java, -Xmx512m, -Xms64m, -XX:PermSize=64m, 
 -XX:MaxPermSize=128m, -cp, 
 /srv/hudson/maven-agent.jar:/srv/hudson/classworlds.jar, 
 hudson.maven.agent.Main, /srv/hudson/tools/maven-2.0.x, 
 /srv/hudson/slave.jar, /srv/hudson/maven-interceptor.jar, 44373] failed
   at hudson.remoting.Channel.call(Channel.java:638)
   at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
   at 
 hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:665)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:420)
   at hudson.model.Run.run(Run.java:1362)
   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:424)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:145)
 Caused by: java.lang.UnsupportedClassVersionError: Bad version number in 
 .class file
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
   at 
 hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:151)
   at 
 hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
   at 
 hudson.plugins.cobertura.MavenCoberturaPublisher.clinit(MavenCoberturaPublisher.java:237)
   at sun.misc.Unsafe.ensureClassInitialized(Native Method)
   at 
 sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
   at 
 sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
   at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
   at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
   at java.lang.reflect.Field.getLong(Field.java:528)
   at 
 java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586)
   at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.io.ObjectStreamClass.init(ObjectStreamClass.java:400)
   at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
   at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
   at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
   at 
 

[JIRA] (JENKINS-13807) Email-ext Plugin Does Not work

[s.sog...@gmail.com (JIRA)]

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

sogabe resolved JENKINS-13807.
--

Resolution: Duplicate

 Email-ext Plugin Does Not work 
 ---

 Key: JENKINS-13807
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13807
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
Affects Versions: current
 Environment: CentOS 6.2, Sun JDK 6.0.31, Jenkins ver. 1.464 installed 
 from yum repo
Reporter: Jared Griffith
  Labels: plugin

 I have installed and tried to activate the email-ext plugin, but when I try 
 to enable the extension for a particular job, it does not work.  I am getting 
 the following error with the Firefox Javascript debugger:
 Timestamp: 05/16/2012 06:16:42 PM
 Error: emailExtInit is not defined
 Source File: 
 http://jenkins.picsauditing.com/static/5f664cc9/scripts/hudson-behavior.js
 Line: 480
 Please help.
 The latest version of the plug in is installed and was installed from the 
 Jenkins Plugin UI.

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