[JIRA] (JENKINS-12693) urltrigger cannot start: claims "bad major version at offset=6"
[
https://issues.jenkins-ci.org/browse/JENKINS-12693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gbois closed JENKINS-12693.
---
Resolution: Won't Fix
Unfortunately, URLTrigger have to run on Java6+.
Therefore, Java5 is not supported.
> urltrigger cannot start: claims "bad major version at offset=6"
> ---
>
> Key: JENKINS-12693
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12693
> Project: Jenkins
> Issue Type: Bug
> Components: urltrigger
> Environment: Jenkins 1.445, urltrigger 0.10
>Reporter: torbent
>Assignee: gbois
> Attachments: 2012-02-09-urltrigger-major-version.txt.txt
>
>
> The urltrigger plugin refuses to start, gives a stacktrace where this seems
> to be the interesting part:
> {quote}Caused by: java.lang.UnsupportedClassVersionError:
> (com/sun/jersey/api/client/config/ClientConfig) bad major version at offset=6
> {quote}
> Full log attached. I'm not able to test newer releases at the moment, because
> Jenkins 1.446 does not work for me and the latest urltrigger is built as a
> .jpi which Jenkins doesn't support until 1.448.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12793) Why the Post Steps and Post-build Actions are not executed after the build finished
[ https://issues.jenkins-ci.org/browse/JENKINS-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-12793: -- Assignee: (was: Ulli Hafner) Component/s: postbuild-task (was: analysis-core) Wrong component. > Why the Post Steps and Post-build Actions are not executed after the build > finished > --- > > Key: JENKINS-12793 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12793 > Project: Jenkins > Issue Type: Bug > Components: postbuild-task > Environment: Windows >Reporter: dzy dzy >Priority: Critical > Attachments: 11.jpg > > > My question is that The log file is in whole or in part when executed "post > step" or "Post-build Actions". How to get the build result. > I want to get the build result,but there are no any plugins to get the > result.So I did below this: > 1 In my opinion,the "post step" are executed after the build finished. So I > cofigured the job and selected "Run regardless of build result" at "post > step" ,at the same time there is one bat at "execute windows at batch > command". > The bat is used to query the two files "build.xml" and "log". But I can not > find the string "FAILURE" in the "build.xml" and "Finished: > FAILURE" in the file "log". > When the build finished,I queried these 2 files on the disk,the strings are > exists in the two file. > 2 I installed one plugin "Post build task" below "Post-build Actions",I put > the string "FAILURE" into the Log text. but the Script did not executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12795) Log/Report link in Job page is broken when Jenkins is started with a specific prefix
Jose Sa created JENKINS-12795: - Summary: Log/Report link in Job page is broken when Jenkins is started with a specific prefix Key: JENKINS-12795 URL: https://issues.jenkins-ci.org/browse/JENKINS-12795 Project: Jenkins Issue Type: Bug Components: robot-plugin Environment: Robot version 1.2.1 Reporter: Jose Sa Assignee: jpiironen Priority: Minor We are starting Jenkins server with the option "--prefix=/jenkins" which makes all jenkins urls relative to http://hostname:8080/jenkins, however when trying to open the Report Link as setup in the Job it fails to open because the url defined does not contain the prefix that was given when server started. For example, in a job with the url: http://hostname:8080/jenkins/job/JOB_NAME It tries to open the follow link and fails: http://hostname:8080/job/JOB_NAME/69/robot/report/report.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12598) In 2.0 update you need to specify branch for every module
[ https://issues.jenkins-ci.org/browse/JENKINS-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159151#comment-159151 ] Ulli Hafner commented on JENKINS-12598: --- I think that would be a good idea. This will allow both use cases. > In 2.0 update you need to specify branch for every module > - > > Key: JENKINS-12598 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12598 > Project: Jenkins > Issue Type: Improvement > Components: cvs >Reporter: Ulli Hafner >Priority: Critical > Attachments: Jenkins_CvsPluginModules.png > > > After an upgrade to the new 2.0 version of the cvs plug-in we now need to > specify the "Module location" (trunk, branch) for each module. This is quite > cumbersome if you have a lot of modules. In the 1.x plug-in releases you are > able to select a given branch for all modules in one text field. > While I think the new "feature" has a lot of use cases (i.e., having trunk > and branches mixed), the usability could be improved here. My requirement is > to select/change the branch (or trunk) for all modules in a simple way. > A non-Ajax suggestion would be to have a "default" entry in the Selection, > i.e. Trunk, Branch, Tag, Default. And you can define the default behavior at > the top of the cvs configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12669) ec2 plugin fails to launch slave with "The instance ID 'i-xxxx' does not exist" about 50% of the time
[ https://issues.jenkins-ci.org/browse/JENKINS-12669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159153#comment-159153 ] Sam He commented on JENKINS-12669: -- I always encounter this issue when I have > 2 EC Region config. > ec2 plugin fails to launch slave with "The instance ID 'i-' does not > exist" about 50% of the time > - > > Key: JENKINS-12669 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12669 > Project: Jenkins > Issue Type: Bug > Components: ec2 >Reporter: Jon Hyman >Assignee: Kohsuke Kawaguchi >Priority: Minor > > The EC2 plugin fails to launch a slave with this error about half the time. I > had this issue originally on Jenkins 1.443 and upgraded to 1.450 and it still > occurs. > Let me know what else I can provide for this issue. > ERROR: Client error : The instance ID 'i-331f8856' does not exist > com.xerox.amazonws.ec2.EC2Exception: Client error : The instance ID > 'i-331f8856' does not exist > at com.xerox.amazonws.ec2.Jec2.makeRequestInt(Jec2.java:2359) > at com.xerox.amazonws.ec2.Jec2.describeInstances(Jec2.java:826) > at hudson.plugins.ec2.EC2Computer._describeInstance(EC2Computer.java:94) > at hudson.plugins.ec2.EC2Computer.getState(EC2Computer.java:75) > at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:29) > at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12781) Jenkins hangs after printing Recording test results
[ https://issues.jenkins-ci.org/browse/JENKINS-12781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159152#comment-159152 ] Matti Linnanvuori commented on JENKINS-12781: - I started the job again after stopping the previous run. The job seemed to hang again, so I took the remote node, on which the job was executed, offline with the Jenkins GUI, which stopped the job. I took the node online again and started the job and this time it did not hang. > Jenkins hangs after printing Recording test results > --- > > Key: JENKINS-12781 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12781 > Project: Jenkins > Issue Type: Bug > Components: junit > Environment: Debian GNU/Linux 6.0 Linux 2.6.32-5-xen-amd64 >Reporter: Matti Linnanvuori > > Jenkins hangs after printing Recording test results. It has been in that > state almost an hour now. > Jenkins version 1.430 > Full thread dump OpenJDK 64-Bit Server VM (14.0-b16 mixed mode): > "pool-25-thread-7394" prio=10 tid=0x7f8c588fd800 nid=0x1a85 waiting on > condition [0x7f8c7084f000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > "pool-25-thread-7393" prio=10 tid=0x7f8c588fc000 nid=0x1a84 waiting on > condition [0x7f8c7064d000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > "pool-25-thread-7392" prio=10 tid=0x7f8c587e6000 nid=0x1a83 waiting on > condition [0x7f8c726c2000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > "pool-25-thread-7391" prio=10 tid=0x7f8c587e5000 nid=0x1a82 waiting on > condition [0x7f8c7074e000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at > java.util.concurrent.ThreadPoolExec
[JIRA] (JENKINS-12781) Jenkins hangs after printing Recording test results
[ https://issues.jenkins-ci.org/browse/JENKINS-12781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159154#comment-159154 ] Matti Linnanvuori commented on JENKINS-12781: - When I took the remote node offline, I got the following error: Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:681) at hudson.FilePath.act(FilePath.java:747) at hudson.FilePath.act(FilePath.java:740) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:668) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:646) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:615) at hudson.model.Run.run(Run.java:1401) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:732) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:826) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1106) Caused by: hudson.remoting.Channel$OrderlyShutdown ... 2 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:62) at hudson.remoting.Command.(Command.java:47) at hudson.remoting.Channel$CloseCommand.(Channel.java:822) at hudson.remoting.Channel$CloseCommand.(Channel.java:822) at hudson.remoting.Channel.close(Channel.java:867) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:825) ... 1 more > Jenkins hangs after printing Recording test results > --- > > Key: JENKINS-12781 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12781 > Project: Jenkins > Issue Type: Bug > Components: junit > Environment: Debian GNU/Linux 6.0 Linux 2.6.32-5-xen-amd64 >Reporter: Matti Linnanvuori > > Jenkins hangs after printing Recording test results. It has been in that > state almost an hour now. > Jenkins version 1.430 > Full thread dump OpenJDK 64-Bit Server VM (14.0-b16 mixed mode): > "pool-25-thread-7394" prio=10 tid=0x7f8c588fd800 nid=0x1a85 waiting on > condition [0x7f8c7084f000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > "pool-25-thread-7393" prio=10 tid=0x7f8c588fc000 nid=0x1a84 waiting on > condition [0x7f8c7064d000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7f8c996391f0> (a > java.util.concurrent.SynchronousQueue$TransferStack) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:453) > at > java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:352) > at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903) > at
[JIRA] (JENKINS-9939) Publisher hudson.tasks.Mailer aborted due to exception
[ https://issues.jenkins-ci.org/browse/JENKINS-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159155#comment-159155 ] Matti Linnanvuori commented on JENKINS-9939: I got the Mailer NullPointException when I took the remote node, on which the job was executing, offline. Jenkins ver. 1.430. Debian GNU/Linux 6.0, 2.6.32-5-xen-amd64. I have the following options on: Send e-mail for every unstable build Send separate e-mails to individuals who broke the build The following was in Console Output: Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:681) at hudson.FilePath.act(FilePath.java:747) at hudson.FilePath.act(FilePath.java:740) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:668) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:646) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:615) at hudson.model.Run.run(Run.java:1401) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:732) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:826) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1106) Caused by: hudson.remoting.Channel$OrderlyShutdown ... 2 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:62) at hudson.remoting.Command.(Command.java:47) at hudson.remoting.Channel$CloseCommand.(Channel.java:822) at hudson.remoting.Channel$CloseCommand.(Channel.java:822) at hudson.remoting.Channel.close(Channel.java:867) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:825) ... 1 more ERROR: Publisher hudson.tasks.Mailer aborted due to exception java.lang.NullPointerException > Publisher hudson.tasks.Mailer aborted due to exception > -- > > Key: JENKINS-9939 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9939 > Project: Jenkins > Issue Type: Bug > Components: mail >Affects Versions: current > Environment: Hudson/Jenkins v1.377, Win Server 2003 R2 x64 SP2 >Reporter: robsimon > > with Hudson/Jenkins v1.377 > ERROR: Publisher hudson.tasks.Mailer aborted due to exception > java.lang.NullPointerException > at hudson.tasks.MailSender.createFailureMail(MailSender.java:271) > at hudson.tasks.MailSender.getMail(MailSender.java:146) > at hudson.tasks.MailSender.execute(MailSender.java:94) > at hudson.tasks.Mailer.perform(Mailer.java:111) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:580) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:558) > at hudson.model.Build$RunnerImpl.post2(Build.java:157) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) > at hudson.model.Run.run(Run.java:1296) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:137) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7883) Stopped (as opposed to terminated) slaves are counted against the active instance count for the purpose of launching; can prevent launching of instances
[ https://issues.jenkins-ci.org/browse/JENKINS-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159156#comment-159156 ] akostadinov commented on JENKINS-7883: -- It's important to count only jenkins instances because otherwise account needs to be dedicated to jenkins. Perhaps make it an option with default value whatever you want but have this capability. > Stopped (as opposed to terminated) slaves are counted against the active > instance count for the purpose of launching; can prevent launching of > instances > > > Key: JENKINS-7883 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7883 > Project: Jenkins > Issue Type: Bug > Components: ec2 >Affects Versions: current > Environment: ubuntu amd64 e.g. alestic ami-da0cf8b3 > ec2 plugin v 1.9 >Reporter: truher >Assignee: francis Upton >Priority: Blocker > > i can manually create slaves, but they are never created automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12796) support templating build steps
Guy Rozendorn created JENKINS-12796: --- Summary: support templating build steps Key: JENKINS-12796 URL: https://issues.jenkins-ci.org/browse/JENKINS-12796 Project: Jenkins Issue Type: New Feature Components: template-project Reporter: Guy Rozendorn Assignee: huybrechts We have a lot of jobs that only differ by: * The slaves the execute the job (different matrixes) * The git repositories they pull Until now we manually copied/synced the configuration of all the jobs (around 20), and we are tired of it. We looked at the template plugin, but its not enough since the jobs using the template do not take the build steps of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7883) Stopped (as opposed to terminated) slaves are counted against the active instance count for the purpose of launching; can prevent launching of instances
[ https://issues.jenkins-ci.org/browse/JENKINS-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159157#comment-159157 ] francis Upton commented on JENKINS-7883: @akostadinov - please open a new JIRA requesting that, it's really not part of this issue. > Stopped (as opposed to terminated) slaves are counted against the active > instance count for the purpose of launching; can prevent launching of > instances > > > Key: JENKINS-7883 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7883 > Project: Jenkins > Issue Type: Bug > Components: ec2 >Affects Versions: current > Environment: ubuntu amd64 e.g. alestic ami-da0cf8b3 > ec2 plugin v 1.9 >Reporter: truher >Assignee: francis Upton >Priority: Blocker > > i can manually create slaves, but they are never created automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12796) support templating build steps
[ https://issues.jenkins-ci.org/browse/JENKINS-12796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guy Rozendorn closed JENKINS-12796. --- Resolution: Cannot Reproduce Didn't see the option before. it works. > support templating build steps > -- > > Key: JENKINS-12796 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12796 > Project: Jenkins > Issue Type: New Feature > Components: template-project >Reporter: Guy Rozendorn >Assignee: huybrechts > > We have a lot of jobs that only differ by: > * The slaves the execute the job (different matrixes) > * The git repositories they pull > Until now we manually copied/synced the configuration of all the jobs (around > 20), and we are tired of it. > We looked at the template plugin, but its not enough since the jobs using the > template do not take the build steps of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12797) "Don't Keep this build forever" button doesn't work on matrix job and prevent removing old build
stibbons created JENKINS-12797: -- Summary: "Don't Keep this build forever" button doesn't work on matrix job and prevent removing old build Key: JENKINS-12797 URL: https://issues.jenkins-ci.org/browse/JENKINS-12797 Project: Jenkins Issue Type: Bug Components: matrix Reporter: stibbons I've several matrix jobs in which I would like to clean old builds, but they are in a "Keep this build forever" state. When I click on the "Don't keep this build forever", it doesn't do anything. In other matrix jobs I can remove the "keep forever" state and then delete the build, but other no. It ends up taking lot of space ! Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12797) "Don't Keep this build forever" button doesn't work on some matrix job and prevent removing old build
[ https://issues.jenkins-ci.org/browse/JENKINS-12797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stibbons updated JENKINS-12797: --- Summary: "Don't Keep this build forever" button doesn't work on some matrix job and prevent removing old build (was: "Don't Keep this build forever" button doesn't work on matrix job and prevent removing old build) > "Don't Keep this build forever" button doesn't work on some matrix job and > prevent removing old build > - > > Key: JENKINS-12797 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12797 > Project: Jenkins > Issue Type: Bug > Components: matrix >Reporter: stibbons > > I've several matrix jobs in which I would like to clean old builds, but they > are in a "Keep this build forever" state. > When I click on the "Don't keep this build forever", it doesn't do anything. > In other matrix jobs I can remove the "keep forever" state and then delete > the build, but other no. It ends up taking lot of space ! > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12798) Plugin does not generate test-reports
Robert Labus created JENKINS-12798: -- Summary: Plugin does not generate test-reports Key: JENKINS-12798 URL: https://issues.jenkins-ci.org/browse/JENKINS-12798 Project: Jenkins Issue Type: Bug Components: xcode Affects Versions: current Environment: Mac OSX Reporter: Robert Labus Fix For: current A plugin should parse a build output and produce test-reports file, but it's simply not doing it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12688) Build hangs on Windows 2008 x64 slave
[ https://issues.jenkins-ci.org/browse/JENKINS-12688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Costin Caraivan updated JENKINS-12688: -- Environment: Jenkins 1.437 and 1.450 Master - Windows 2008 x64, Java 1.6.0_29 Slave - Windows 2008 x64 service (also tried JNLP), Java 1.6.0._29 was: Jenkins 1.437 Master - Windows 2008 x64, Java 1.6.0_29 Slave - Windows 2008 x64 service (also tried JNLP), Java 1.6.0._29 > Build hangs on Windows 2008 x64 slave > - > > Key: JENKINS-12688 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12688 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Jenkins 1.437 and 1.450 > Master - Windows 2008 x64, Java 1.6.0_29 > Slave - Windows 2008 x64 service (also tried JNLP), Java 1.6.0._29 >Reporter: Costin Caraivan >Priority: Blocker > Attachments: huskar-sysinfo.txt > > > We have some integration tests launched from freestyle jobs. They are MSBuild > projects which launch Nunit tests. > The main build steps run ok and are over in ~17-18 minutes. However, the > build hangs at the end - where the communication with the master is supposed > to happen (for example when publishing the reports, or when sending the email > notification). I've removed the email notification and the Nunit report > publishing, and the build still hangs: > "Time Elapsed 00:16:10.09 > Build step 'Build a Visual Studio project or solution using MSBuild.' marked > build as failure"). > We've had build hanging for as much as 11 hours (!). > I've tried different connection settings: Windows service, JNLP - nothing > helps. > I'll attach the server & slave dumps. > If there are any fixes for this, that I missed in the recent changelogs, I'll > update Jenkins. But I don't see any possible fixes for this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12688) Build hangs on Windows 2008 x64 slave
[ https://issues.jenkins-ci.org/browse/JENKINS-12688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159159#comment-159159 ] Costin Caraivan commented on JENKINS-12688: --- Upgraded to 1.450, same issue. > Build hangs on Windows 2008 x64 slave > - > > Key: JENKINS-12688 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12688 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Jenkins 1.437 > Master - Windows 2008 x64, Java 1.6.0_29 > Slave - Windows 2008 x64 service (also tried JNLP), Java 1.6.0._29 >Reporter: Costin Caraivan >Priority: Blocker > Attachments: huskar-sysinfo.txt > > > We have some integration tests launched from freestyle jobs. They are MSBuild > projects which launch Nunit tests. > The main build steps run ok and are over in ~17-18 minutes. However, the > build hangs at the end - where the communication with the master is supposed > to happen (for example when publishing the reports, or when sending the email > notification). I've removed the email notification and the Nunit report > publishing, and the build still hangs: > "Time Elapsed 00:16:10.09 > Build step 'Build a Visual Studio project or solution using MSBuild.' marked > build as failure"). > We've had build hanging for as much as 11 hours (!). > I've tried different connection settings: Windows service, JNLP - nothing > helps. > I'll attach the server & slave dumps. > If there are any fixes for this, that I missed in the recent changelogs, I'll > update Jenkins. But I don't see any possible fixes for this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
Ed Randall created JENKINS-12799: Summary: When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data Key: JENKINS-12799 URL: https://issues.jenkins-ci.org/browse/JENKINS-12799 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: Jenkins 1.424.2 Promoted Builds 2.4 Reporter: Ed Randall Priority: Minor Attachments: jenkins-build-history.png, jenkins-promotion-history.png I've been experimenting with different configurations for promoting builds, now when the promotion happens I'm getting no less than 3 stars applied alongside the build name. Two of them should not be there for two reasons (1) because they are based on configuration information that is no longer part of the job configuration, it should have been overwritten; (2) They actually fail according to their own status! Please see attached screenshots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
[ https://issues.jenkins-ci.org/browse/JENKINS-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated JENKINS-12799: - Attachment: jenkins-job-promotion-config.png > When project configuration is changed, Promoted Builds Plugin continues to > use "old" configuration data > --- > > Key: JENKINS-12799 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12799 > Project: Jenkins > Issue Type: Bug > Components: promoted-builds >Affects Versions: current > Environment: Jenkins 1.424.2 > Promoted Builds 2.4 >Reporter: Ed Randall >Priority: Minor > Attachments: jenkins-build-history.png, > jenkins-job-promotion-config.png, jenkins-promotion-history.png > > > I've been experimenting with different configurations for promoting builds, > now when the promotion happens I'm getting no less than 3 stars applied > alongside the build name. > Two of them should not be there for two reasons > (1) because they are based on configuration information that is no longer > part of the job configuration, it should have been overwritten; > (2) They actually fail according to their own status! > Please see attached screenshots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12800) Can't add xcodebuild parameters including whitespace
Sven Weidauer created JENKINS-12800: --- Summary: Can't add xcodebuild parameters including whitespace Key: JENKINS-12800 URL: https://issues.jenkins-ci.org/browse/JENKINS-12800 Project: Jenkins Issue Type: Bug Components: xcode Affects Versions: current Reporter: Sven Weidauer I am trying to pass the parameter 'CODE_SIGN_IDENTITY="iPhone Distribution"' to xcodebuild via the new 'custom xcodebuild arguments' field. But no matter how I quote this it always gets split into two paramters at the whitespace which makes the build fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1519) PMD: plugin tries to read files from master in stead of slave
[ https://issues.jenkins-ci.org/browse/JENKINS-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cees Bos closed JENKINS-1519. - Resolution: Fixed This is fixed a long time ago > PMD: plugin tries to read files from master in stead of slave > - > > Key: JENKINS-1519 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1519 > Project: Jenkins > Issue Type: Bug > Components: pmd >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: Cees Bos > > I have installed the PMD plugin and use it. (We also have installed the > violations plugin and I want to compare them). > When I drill down in the report I get the page with packages. There I can > drill > down top the file overview. From therer I can drill down to the code of the > file. > There I get: Can't read file /path/to/file.java (No such file or directory) > This path is a path which exists on the slave, but my feeling is that it tries > to read it on the master. > Is this plugin tested in a master/slave configuration of Hudson? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
Cees Bos created JENKINS-12801:
--
Summary: When there are 2 PMD warnings on 1 line the Jenkins
report does only report 1
Key: JENKINS-12801
URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
Project: Jenkins
Issue Type: Bug
Components: pmd
Reporter: Cees Bos
Assignee: Ulli Hafner
We have this line of code:
{code:java}
public boolean hasNext()
{
return cursor == EMPTY && entity != EMPTY;
}
{code}
PMD xml report has these violations reported:
{code:xml}
http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
priority="3">
Use equals() to compare object references.
http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
priority="3">
Use equals() to compare object references.
{code}
Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
In the UI it is only reported once.
And the total number of violations does not match with the actual number of
violations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12761) tfs plugin :failed to record scm polling
[ https://issues.jenkins-ci.org/browse/JENKINS-12761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12761 started by drewrm. > tfs plugin :failed to record scm polling > - > > Key: JENKINS-12761 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12761 > Project: Jenkins > Issue Type: Bug > Components: tfs >Affects Versions: current > Environment: Computer : windows xp/7 ,x86 Architecture > Tomcat :Version 7.0.11 > Jenkins:Version 1.450 > tfs plugin:Version 1.20 >Reporter: jlin sai >Assignee: drewrm > Labels: plugin > Fix For: current > > Attachments: ErrorInfo.jpg > > > I get a failure when I use the tfs plugin of Jenkins. > The Source Code management tool what I use is Team Foundation Server > 2010,when I manage the poll SCM in Jenkins,and want to trigger a build > automatic when it detected a change between TFS server and Personal workspace > , a failure hanppened ,which information is "failed to record scm polling". > Three months ago ,the version of tfs plugin is 1.17,I encount the failure > ,and now the problem isn't resolved. I have been searched a method for a long > time ,but not get it . > I don't know what the reason is ,so please to help me to fixed the > problem.Thank you very much! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12761) tfs plugin :failed to record scm polling
[ https://issues.jenkins-ci.org/browse/JENKINS-12761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12761 stopped by jlin sai. > tfs plugin :failed to record scm polling > - > > Key: JENKINS-12761 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12761 > Project: Jenkins > Issue Type: Bug > Components: tfs >Affects Versions: current > Environment: Computer : windows xp/7 ,x86 Architecture > Tomcat :Version 7.0.11 > Jenkins:Version 1.450 > tfs plugin:Version 1.20 >Reporter: jlin sai >Assignee: drewrm > Labels: plugin > Fix For: current > > Attachments: ErrorInfo.jpg > > > I get a failure when I use the tfs plugin of Jenkins. > The Source Code management tool what I use is Team Foundation Server > 2010,when I manage the poll SCM in Jenkins,and want to trigger a build > automatic when it detected a change between TFS server and Personal workspace > , a failure hanppened ,which information is "failed to record scm polling". > Three months ago ,the version of tfs plugin is 1.17,I encount the failure > ,and now the problem isn't resolved. I have been searched a method for a long > time ,but not get it . > I don't know what the reason is ,so please to help me to fixed the > problem.Thank you very much! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12802) Initial select box validation fails when default value is provided.
Ben Ripkens created JENKINS-12802:
-
Summary: Initial select box validation fails when default value is
provided.
Key: JENKINS-12802
URL: https://issues.jenkins-ci.org/browse/JENKINS-12802
Project: Jenkins
Issue Type: Bug
Components: jenkins-plugin-runtime, plugin
Affects Versions: current
Environment: Jenkins version 1.451.
Jenkins run through mvn hpi:run.
See system info in attachment for further information.
Browser: Google Chrome 17 and Firefox 10
Reporter: Ben Ripkens
Assignee: Jørgen Tjernø
Attachments: systeminfo.pdf
When defining a select box like this:
{code:xml}
{code}
and validating the value through a
{code:java}
int i = 0;
public FormValidation doCheckVcs(@QueryParameter String value) {
System.out.println(i + ": value: " + value);
i++;
try {
VersionControlSystem.valueOf(value);
return FormValidation.ok();
} catch (IllegalArgumentException ex) {
return FormValidation.error("Please select one of the Version Control
Systems.");
}
}
{code}
method, it can be observed that the validation method is called two times when
opening the configuration menu (http://localhost:8080/configure). The first
time, the correct default value, i.e., the selected item's value, is passed to
the validation method. The second time, no data is passed in (see following
code listing for output).
{code}
0: value: MERCURIAL
1: value:
{code}
The code is additionally available on GitHub:
Descriptor:
https://github.com/bripkens/janus-plugin/blob/389833439d11cc4daf5666c1ac7fb98ecad28471/src/main/java/de/codecentric/janus/plugin/Root.java
Jelly:
https://github.com/bripkens/janus-plugin/blob/389833439d11cc4daf5666c1ac7fb98ecad28471/src/main/resources/de/codecentric/janus/plugin/Root/global.jelly
Data is provided in the following way:
{code:java}
public ListBoxModel doFillVcsItems() {
ListBoxModel m = new ListBoxModel();
m.add("Please select", "");
for (VersionControlSystem vcs : VersionControlSystem.values()) {
if (this.vcs == vcs) {
m.add(new ListBoxModel.Option(vcs.name(), vcs.name(),
true));
} else {
m.add(vcs.name());
}
}
return m;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12803) Installing plugin (without restarting) is broken with other non-refreshable extension.
Gavriil Konovalenko created JENKINS-12803: - Summary: Installing plugin (without restarting) is broken with other non-refreshable extension. Key: JENKINS-12803 URL: https://issues.jenkins-ci.org/browse/JENKINS-12803 Project: Jenkins Issue Type: Bug Components: update-center Affects Versions: current Reporter: Gavriil Konovalenko Priority: Minor Fix For: current Installing plugins without restart don't work in case if non-refreshable extension is activated. In my case I had https://wiki.jenkins-ci.org/display/JENKINS/Persona+Plugin installed, and received following exception: hudson.util.IOException2: Failed to dynamically deploy this plugin at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1137) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:955) 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:662) Caused by: hudson.util.IOException2: Failed to install build-name-setter-plugin plugin at hudson.PluginManager.dynamicLoad(PluginManager.java:365) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1133) ... 7 more Caused by: jenkins.ExtensionRefreshException: hudson.plugins.persona.xml.XmlPersonaFinder@1664d71 doesn't support refresh at jenkins.model.Jenkins.refreshExtensions(Jenkins.java:1970) at hudson.PluginManager.dynamicLoad(PluginManager.java:358) ... 8 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12802) Initial select box validation fails when default value is provided.
[
https://issues.jenkins-ci.org/browse/JENKINS-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159161#comment-159161
]
Ben Ripkens commented on JENKINS-12802:
---
I should note that the validation is done two times for a single request. The
second of which fails due to the empty string.
> Initial select box validation fails when default value is provided.
> ---
>
> Key: JENKINS-12802
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12802
> Project: Jenkins
> Issue Type: Bug
> Components: jenkins-plugin-runtime, plugin
>Affects Versions: current
> Environment: Jenkins version 1.451.
> Jenkins run through mvn hpi:run.
> See system info in attachment for further information.
> Browser: Google Chrome 17 and Firefox 10
>Reporter: Ben Ripkens
>Assignee: Jørgen Tjernø
> Labels: jelly, jenkins, listbox, plugin
> Attachments: systeminfo.pdf
>
>
> When defining a select box like this:
> {code:xml}
> field="vcs">
>
>
> {code}
> and validating the value through a
> {code:java}
> int i = 0;
> public FormValidation doCheckVcs(@QueryParameter String value) {
>
> System.out.println(i + ": value: " + value);
> i++;
> try {
> VersionControlSystem.valueOf(value);
> return FormValidation.ok();
> } catch (IllegalArgumentException ex) {
> return FormValidation.error("Please select one of the Version Control
> Systems.");
> }
> }
> {code}
> method, it can be observed that the validation method is called two times
> when opening the configuration menu (http://localhost:8080/configure). The
> first time, the correct default value, i.e., the selected item's value, is
> passed to the validation method. The second time, no data is passed in (see
> following code listing for output).
> {code}
> 0: value: MERCURIAL
> 1: value:
> {code}
> The code is additionally available on GitHub:
> Descriptor:
> https://github.com/bripkens/janus-plugin/blob/389833439d11cc4daf5666c1ac7fb98ecad28471/src/main/java/de/codecentric/janus/plugin/Root.java
> Jelly:
> https://github.com/bripkens/janus-plugin/blob/389833439d11cc4daf5666c1ac7fb98ecad28471/src/main/resources/de/codecentric/janus/plugin/Root/global.jelly
> Data is provided in the following way:
> {code:java}
> public ListBoxModel doFillVcsItems() {
> ListBoxModel m = new ListBoxModel();
> m.add("Please select", "");
> for (VersionControlSystem vcs : VersionControlSystem.values()) {
> if (this.vcs == vcs) {
> m.add(new ListBoxModel.Option(vcs.name(), vcs.name(),
> true));
> } else {
> m.add(vcs.name());
> }
>
> }
> return m;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12803) Installing plugin (without restarting) is broken with other non-refreshable extension.
[ https://issues.jenkins-ci.org/browse/JENKINS-12803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159162#comment-159162 ] Gavriil Konovalenko commented on JENKINS-12803: --- In the code, I see that ExtensionRefreshException thrown in Jenkins.refreshExtensions() is handled to raise IOException2 and fail plugin installation process. So it seems that such behavior is by design? If so, then I'd suggest to change this behavior, and this bug report should be reclassified as feature request. > Installing plugin (without restarting) is broken with other non-refreshable > extension. > -- > > Key: JENKINS-12803 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12803 > Project: Jenkins > Issue Type: Bug > Components: update-center >Affects Versions: current >Reporter: Gavriil Konovalenko >Priority: Minor > Labels: exception, install, jenkins, plugin > Fix For: current > > > Installing plugins without restart don't work in case if non-refreshable > extension is activated. In my case I had > https://wiki.jenkins-ci.org/display/JENKINS/Persona+Plugin installed, and > received following exception: > hudson.util.IOException2: Failed to dynamically deploy this plugin > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1137) > at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:955) > 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:662) > Caused by: hudson.util.IOException2: Failed to install > build-name-setter-plugin plugin > at hudson.PluginManager.dynamicLoad(PluginManager.java:365) > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1133) > ... 7 more > Caused by: jenkins.ExtensionRefreshException: > hudson.plugins.persona.xml.XmlPersonaFinder@1664d71 doesn't support refresh > at jenkins.model.Jenkins.refreshExtensions(Jenkins.java:1970) > at hudson.PluginManager.dynamicLoad(PluginManager.java:358) > ... 8 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12685) There is no way to escape a $ so that it can be used without an exception
[ https://issues.jenkins-ci.org/browse/JENKINS-12685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe resolved JENKINS-12685. -- Resolution: Fixed > There is no way to escape a $ so that it can be used without an exception > - > > Key: JENKINS-12685 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12685 > Project: Jenkins > Issue Type: Bug > Components: token-macro >Affects Versions: current > Environment: Token Macro 1.5 >Reporter: Slide-O-Mix >Assignee: Kohsuke Kawaguchi >Priority: Minor > > With the token macro plugin, if I have something like the following "$4000" > in my text, there is an exception for unknown macro thrown. There should be a > way to escape the $ so that you can actually use a $ in the text of something > that is going to be replaced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11749) Included regions feature for GitSCM plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159163#comment-159163 ] Gregory Pakosz commented on JENKINS-11749: -- I would love to see this added to GitSCM. Our repo contains multiple component with separate build systems and such an included regions filter would be really useful. > Included regions feature for GitSCM plugin > -- > > Key: JENKINS-11749 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11749 > Project: Jenkins > Issue Type: New Feature > Components: git >Affects Versions: current >Reporter: Juerg Haefliger >Assignee: Juerg Haefliger >Priority: Minor > > For having several regions to be excluded from build its better to filter the > building process only for some included regions. > [Description copied from http://issues.hudson-ci.org/browse/HUDSON-7294] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11749) Included regions feature for GitSCM plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159163#comment-159163 ] Gregory Pakosz edited comment on JENKINS-11749 at 2/16/12 1:19 PM: --- I would love to see this added to GitSCM. Our repo contains multiple component with separate build systems and such an included regions filter would be really useful. Also Juerg did the job in the following pull request: https://github.com/jenkinsci/git-plugin/pull/49 was (Author: gpakosz): I would love to see this added to GitSCM. Our repo contains multiple component with separate build systems and such an included regions filter would be really useful. > Included regions feature for GitSCM plugin > -- > > Key: JENKINS-11749 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11749 > Project: Jenkins > Issue Type: New Feature > Components: git >Affects Versions: current >Reporter: Juerg Haefliger >Assignee: Juerg Haefliger >Priority: Minor > > For having several regions to be excluded from build its better to filter the > building process only for some included regions. > [Description copied from http://issues.hudson-ci.org/browse/HUDSON-7294] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12804) Promote "When the following upstream promotions are promoted" does not happen
Ed Randall created JENKINS-12804: Summary: Promote "When the following upstream promotions are promoted" does not happen Key: JENKINS-12804 URL: https://issues.jenkins-ci.org/browse/JENKINS-12804 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: Jenkins 1.424.2 Promoted-builds-plugin 2.4 parameterized trigger plugin 2.12 Reporter: Ed Randall I have a "quicktest" job set to: "Promote immediately once the build is complete" and nothing else. This should happen automatically when the tests complete and they all pass, ie when "stable". This works; the promotion is named "Bedrock-DEV-GF-EL-quicktest promoted" The "quicktest" job triggers (via parameterized trigger plugin) a downstream job "zipfile" which packages the project for release to QA, if "quicktest" is stable. The zipfile job is set promote: "Promote immediately once the build is complete" && "When the following upstream promotions are promoted" promotion names: "Bedrock-DEV-GF-EL-quicktest promoted" I'd expect this zipfile job to get promoted, but it doesn't happen; The Promotion status screen says: Bedrock-DEV-GF-EL-zipfile promoted This promotion has not happened. Met Qualification Automatically promoted immediately after the build Unmet Qualification Upstream promotions Bedrock-DEV-GF-EL-quicktest promoted -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[ https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159164#comment-159164 ] Massimo Rossello commented on JENKINS-11926: Hi, I confirm that the Windows master (Jenkins 1.450) + Linux slave configuration DOES NOT work with 3.27. I see no progress at all. This problem is coupled (as before) with a strange behavior on the master configuration page. Whenever the example parsed text is over about 250 characters, a match is no more found (even if more text is appended after a previously matched text). Regards > Warnings plugin does not work on a slave > > > Key: JENKINS-11926 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11926 > Project: Jenkins > Issue Type: Bug > Components: warnings >Affects Versions: current > Environment: Tried both with: > - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24 > - a linux box (different from the above) acting both as master and slave, > Jenkins 1.440, Warnings 3.24 >Reporter: Massimo Rossello >Assignee: Ulli Hafner > Labels: plugin, slave, warnings > > I create my own parser. If I use the Warning parsing on the master it works > as expected. If I make the parsing on the slave it always reports 0 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[
https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159164#comment-159164
]
Massimo Rossello edited comment on JENKINS-11926 at 2/16/12 2:05 PM:
-
Hi,
I confirm that the Windows master (Jenkins 1.450) + Linux slave configuration
DOES NOT work with 3.27. I see no progress at all.
This problem is coupled (as before) with a strange behavior on the master
configuration page. Whenever the example parsed text is over about 250
characters, a match is no more found (even if more text is appended after a
previously matched text).
Here is my current output:
{code}
[WARNINGS] Parsing warnings in files 'reports/flexelint.txt' with parser
AzcomLint
[WARNINGS] Parsing 1 files in
/opt/server/jenkins/workspace/customer1_continuous_trunk
[WARNINGS] Successfully parsed file
/opt/server/jenkins/workspace/customer1_continuous_trunk/reports/flexelint.txt
of module with 0 warnings.
[WARNINGS] Computing warning deltas based on reference build #600
{code}
Regards
was (Author: maxrossello):
Hi,
I confirm that the Windows master (Jenkins 1.450) + Linux slave configuration
DOES NOT work with 3.27. I see no progress at all.
This problem is coupled (as before) with a strange behavior on the master
configuration page. Whenever the example parsed text is over about 250
characters, a match is no more found (even if more text is appended after a
previously matched text).
Regards
> Warnings plugin does not work on a slave
>
>
> Key: JENKINS-11926
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11926
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Affects Versions: current
> Environment: Tried both with:
> - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24
> - a linux box (different from the above) acting both as master and slave,
> Jenkins 1.440, Warnings 3.24
>Reporter: Massimo Rossello
>Assignee: Ulli Hafner
> Labels: plugin, slave, warnings
>
> I create my own parser. If I use the Warning parsing on the master it works
> as expected. If I make the parsing on the slave it always reports 0 warnings
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12280) Warnings plugin does strange things with a custom parser
[
https://issues.jenkins-ci.org/browse/JENKINS-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159165#comment-159165
]
torbent commented on JENKINS-12280:
---
Sorry about the delay.
Just checked. Running Jenkins 1.445 and Warnings plugin 3.27 on a test-ish
setup.
Both master and slave are Linux-based.
I get all the warnings I expect, so it seems to be working for me :-)
Now I'll take it into our production environment and check it. It has a Linux
server and both Linux and Windows based slaves. I'll get back tomorrow with the
results of that test.
> Warnings plugin does strange things with a custom parser
>
>
> Key: JENKINS-12280
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12280
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
> Environment: Linux master, Windows slave.
> Jenkins 1.441, Warnings 3.24.
>Reporter: torbent
>Assignee: Ulli Hafner
>
> I configured a parser in the main Configure section and verified that it
> would match and report a warning. However, it would only report one even if I
> copied extra lines?
> During an actual build (on the slave) it is reported to be run. I see the
> correct parser name (that I gave it), the correct file name of the log file,
> and it claims to have found 4 warnings ("Successfully parsed ... with 4
> warnings").
> The problems are:
> - There should, by my count, be 18 warnings
> - It doesn't actually report warnings from the parser in the "Warnings" result
> There is one other warning parser involved, an MSBuild parser. There are 2
> warnings from that (correct), and I also get 2 warnings from the _not
> configured_ "PC-Lint" parser. The alleged PC-Lint warnings are identical to
> the MSBuild warnings, apart from the type.
> No warnings are reported for my parser.
> It could look like there's some mix-up of parsers? Is this by any chance
> related to JENKINS-11926?
> Further details:
> - Both warnings parsers are run on the same file.
> - The warnings I want to parse do not have file names nor line numbers. I've
> tried putting both "some text" and "" as file name, and 0 or 1 for line
> number. Neither worked any differently.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12390) Jira plugin cannot be configured to connect to Atlassian on demand instances
[ https://issues.jenkins-ci.org/browse/JENKINS-12390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159166#comment-159166 ] Henry Cavillones commented on JENKINS-12390: This seems to be an easy fix..Be nice if it worked > Jira plugin cannot be configured to connect to Atlassian on demand instances > > > Key: JENKINS-12390 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12390 > Project: Jenkins > Issue Type: Bug > Components: jira, plugin >Reporter: Sven H. > > When configuring https://whatevername.atlassian.net it fails with 'This is a > valid URL but it doesn't look like JIRA' > Rootcause: > source: JiraProjectProperty.java > if (!findText(open(new URL(url)), "Atlassian JIRA")) > fails because the on-demand site does not contain that string, rather > "Atlassian" only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9041) Analysis Core / SSL Problem
[ https://issues.jenkins-ci.org/browse/JENKINS-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159167#comment-159167 ] recampbell commented on JENKINS-9041: - I can confirm this solves the issue for me as well. > Analysis Core / SSL Problem > --- > > Key: JENKINS-9041 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9041 > Project: Jenkins > Issue Type: Bug > Components: analysis-core, checkstyle, findbugs >Reporter: Felix Gliesche >Assignee: Ulli Hafner > > When using SSL with Hudson, the plugins based on the Analysis Core (such as > Findbugs, Checkstyle, etc.) do show the trend but details under the tabs > remain empty. It seems that AJAX calls do not use the Hudson URL set under > Hudson's system configuration (in our case starting with https://...) . URL > rewriting (from http to https) does not fix this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[ https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-11926: -- Attachment: issue11926.txt Massimo, I think that the problem must be somewhere else. Maybe the output file is different. Would it be possible to attach the output as a file? Or conversely, can you check if the attached file issue11926.txt will be parsed by your parser. > Warnings plugin does not work on a slave > > > Key: JENKINS-11926 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11926 > Project: Jenkins > Issue Type: Bug > Components: warnings >Affects Versions: current > Environment: Tried both with: > - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24 > - a linux box (different from the above) acting both as master and slave, > Jenkins 1.440, Warnings 3.24 >Reporter: Massimo Rossello >Assignee: Ulli Hafner > Labels: plugin, slave, warnings > Attachments: issue11926.txt > > > I create my own parser. If I use the Warning parsing on the master it works > as expected. If I make the parsing on the slave it always reports 0 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[ https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159168#comment-159168 ] Ulli Hafner edited comment on JENKINS-11926 at 2/16/12 5:11 PM: Massimo, I think that the problem must be somewhere else. Maybe the output file is different. Would it be possible to attach the output as a file? Or conversely, can you check if the attached file issue11926.txt will be parsed by your parser if you copy it to the slave (or master). was (Author: drulli): Massimo, I think that the problem must be somewhere else. Maybe the output file is different. Would it be possible to attach the output as a file? Or conversely, can you check if the attached file issue11926.txt will be parsed by your parser. > Warnings plugin does not work on a slave > > > Key: JENKINS-11926 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11926 > Project: Jenkins > Issue Type: Bug > Components: warnings >Affects Versions: current > Environment: Tried both with: > - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24 > - a linux box (different from the above) acting both as master and slave, > Jenkins 1.440, Warnings 3.24 >Reporter: Massimo Rossello >Assignee: Ulli Hafner > Labels: plugin, slave, warnings > Attachments: issue11926.txt > > > I create my own parser. If I use the Warning parsing on the master it works > as expected. If I make the parsing on the slave it always reports 0 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8159) hudson debian pkg install failed on ubuntu 10.04 LTS due to java-virtual-machine dependency
[ https://issues.jenkins-ci.org/browse/JENKINS-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-8159. -- Resolution: Fixed finally fixed according to the last comment > hudson debian pkg install failed on ubuntu 10.04 LTS due to > java-virtual-machine dependency > --- > > Key: JENKINS-8159 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8159 > Project: Jenkins > Issue Type: Bug > Components: deploy > Environment: ubuntu 10.04 LTS >Reporter: rwen > > When attempted to install debian pkg on a linux box running ubuntu 10.04 LTS > according to instructions at http://jenkins-ci.org/debian/, > caught the following errors: > Selecting previously deselected package hudson. > (Reading database ... 156365 files and directories currently installed.) > Unpacking hudson (from /tmp/hudson.deb) ... > dpkg: dependency problems prevent configuration of hudson: > hudson depends on java-virtual-machine; however: > Package java-virtual-machine is not installed. > dpkg: error processing hudson (--install): > dependency problems - leaving unconfigured > Processing triggers for ureadahead ... > I have checked the packages on the machine and java virtual machine, > openjdk-6-jre, was already installed. Is there specific version of jvm that > must be installed in advance? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12184) role management or view configuration leads to server Error 500, and the configuration works in memory but not in Jenkins's config.xml
[
https://issues.jenkins-ci.org/browse/JENKINS-12184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159170#comment-159170
]
pixman20 commented on JENKINS-12184:
I have a similar issue that is occurring. I'm not sure if it is related, but I
am getting error 500 with what appears to be the same common cause:
java.lang.NullPointerException
com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy$ConverterImpl.marshal(RoleBasedAuthorizationStrategy.java:239)
I get this error when trying to save the configuration on Jenkins slave nodes.
The stack trace I am getting is:
java.lang.RuntimeException: Failed to instantiate class hudson.slaves.DumbSlave
from
{"":["hudson.slaves.JNLPLauncher","hudson.slaves.RetentionStrategy$Always"],"labelString":"USER_1059146","launcher":{"stapler-class":"hudson.slaves.JNLPLauncher","tunnel":"","vmargs":""},"mode":"EXCLUSIVE","name":"ftw-sicft02","nodeDescription":"Slave
used to run jobs as
US\\1059146","nodeProperties":{"stapler-class-bag":"true"},"numExecutors":"2","remoteFS":"D:\\jenkins\\slaves\\USER_1059146","retentionStrategy":{"stapler-class":"hudson.slaves.RetentionStrategy$Always"}}
at hudson.model.Descriptor.newInstance(Descriptor.java:568)
at hudson.model.Node.reconfigure(Node.java:410)
at hudson.model.Computer.doConfigSubmit(Computer.java:1069)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
at
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
at
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
at
hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
at
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at
hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66)
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.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegi
[JIRA] (JENKINS-12184) role management or view configuration leads to server Error 500, and the configuration works in memory but not in Jenkins's config.xml
[
https://issues.jenkins-ci.org/browse/JENKINS-12184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159170#comment-159170
]
pixman20 edited comment on JENKINS-12184 at 2/16/12 5:21 PM:
-
I have a similar issue that is occurring. I'm not sure if it is related, but I
am getting error 500 with what appears to be the same common cause:
java.lang.NullPointerException
com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy$ConverterImpl.marshal(RoleBasedAuthorizationStrategy.java:239)
I get this error when trying to save the configuration on Jenkins slave nodes.
The full stack trace I am getting is:
java.lang.RuntimeException: Failed to instantiate class hudson.slaves.DumbSlave
from
{"":["hudson.slaves.JNLPLauncher","hudson.slaves.RetentionStrategy$Always"],"labelString":"USER","launcher":{"stapler-class":"hudson.slaves.JNLPLauncher","tunnel":"","vmargs":""},"mode":"EXCLUSIVE","name":"mynode","nodeDescription":"Slave
used to run jobs as
USER","nodeProperties":{"stapler-class-bag":"true"},"numExecutors":"2","remoteFS":"D:\\jenkins\\slaves\\USER","retentionStrategy":{"stapler-class":"hudson.slaves.RetentionStrategy$Always"}}
at hudson.model.Descriptor.newInstance(Descriptor.java:568)
at hudson.model.Node.reconfigure(Node.java:410)
at hudson.model.Computer.doConfigSubmit(Computer.java:1069)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
at
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
at
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
at
hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
at
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at
hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66)
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.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.ja
[JIRA] (JENKINS-12805) Let Jenkins user to stop/start/restart Selenium grid server (hub)
Tetiana Tvardovska created JENKINS-12805: Summary: Let Jenkins user to stop/start/restart Selenium grid server (hub) Key: JENKINS-12805 URL: https://issues.jenkins-ci.org/browse/JENKINS-12805 Project: Jenkins Issue Type: Improvement Components: selenium Reporter: Tetiana Tvardovska Assignee: Kohsuke Kawaguchi Please add options to restart, stop/start (depending on the current server running state) the Selenium Grid Hub server. Options could be added to "/selenium/" page as links, in similar way as Jenkins plugin "Restart Safely" works. Reason: Sometimes errors happen on Selenium server (grid hub), or on some of Selenium nodes, which require Selenium server to be restarted. Now, to restart the Selenium server, the all Jenkins server should be restarted! This is not a good solution, as there could be long jobs running independently from Selenium. Note: Just "Restart" would be also fine! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4714) Login into hudson failed from IE6/8 (hudson own user database)
[ https://issues.jenkins-ci.org/browse/JENKINS-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159171#comment-159171 ] evernat commented on JENKINS-4714: -- @wohauser And I have not reproduced the issue using "IE 6.0.2900.5512" and Jenkins v1.440. Is there still an issue for you? (by the way, css styles of Jenkins are not perfect when using IE6 but they are readable) > Login into hudson failed from IE6/8 (hudson own user database) > -- > > Key: JENKINS-4714 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4714 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: PC, OS: Linux >Reporter: wohauser > Attachments: hudson_settings.jpg > > > Since version 1.323 we can't login from an Internet Explorer Version 6 > (unfortunitely our company default yet). > IE 8 also don't work > Using Firefox (3.5.3) or Iceweasel (3.0.14) the login works. > On IE 6 we don't get the username, always the "Login" text appears in upper > right corner. > We get no "start build" or administration rights after an login attempt that > don't report errors to the browser. > our security settings: see attachment "Security Settings" > our system: debian lenny (powered by VM-Ware Server 2.0.1) > java: java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) > Any ideas ? > on stdout (debian lenny, hudson 1.324) we got this for IE 6 login attempt: > Sep 21, 2009 2:54:02 PM hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: h.hasPermission(it, permission). > Reason: > java.lang.NullPointerException > java.lang.NullPointerException > at hudson.security.AuthorizationStrategy.getACL > (AuthorizationStrategy.java:102) > at hudson.model.View.getACL(View.java:269) > at hudson.model.View.hasPermission(View.java:277) > at hudson.Functions.hasPermission(Functions.java:581) > at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke > (UberspectImpl.java:258) > at > org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) > at org.apache.commons.jexl.parser.ASTReference.execute > (ASTReference.java:83) > at org.apache.commons.jexl.parser.ASTReference.value > (ASTReference.java:57) > at org.apache.commons.jexl.parser.ASTReferenceExpression.value > (ASTReferenceExpression.java:51) > at org.apache.commons.jexl.ExpressionImpl.evaluate > (ExpressionImpl.java:80) > at hudson.ExpressionFactory2$JexlExpression.evaluate > (ExpressionFactory2.java:72) > at > org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse > (ExpressionSupport.java:61) > at > org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsBoolean > (ExpressionSupport.java:71) > at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:41) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) > at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:81) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) > at org.apache.commons.jelly.impl.StaticTagScript.run > (StaticTagScript.java:112) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) > at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:81) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[ https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159172#comment-159172 ] Massimo Rossello commented on JENKINS-11926: Ok, I will try to parse your attached file as soon as possible. Thanks > Warnings plugin does not work on a slave > > > Key: JENKINS-11926 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11926 > Project: Jenkins > Issue Type: Bug > Components: warnings >Affects Versions: current > Environment: Tried both with: > - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24 > - a linux box (different from the above) acting both as master and slave, > Jenkins 1.440, Warnings 3.24 >Reporter: Massimo Rossello >Assignee: Ulli Hafner > Labels: plugin, slave, warnings > Attachments: issue11926.txt > > > I create my own parser. If I use the Warning parsing on the master it works > as expected. If I make the parsing on the slave it always reports 0 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
Mike Henderson created JENKINS-12806: Summary: Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes Key: JENKINS-12806 URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 Reporter: Mike Henderson Attachments: config.xml I have a job that gathers a lot of different components from Perforce and we recently added a few new lines. After the job built once we attemt to go back into the config screen for the job and the settings come up but we get a "ERROR" just below the mapping that once you click on it it shows a 404 error and after that the user is logged out of Jenkins. If I delete the project mapping from the config.xml and reload from the disk the job is editable again until the next build. I have tried to use the clientspec feature but this also adds back in the key in the config.xml and again the error reoccurs after the first build. Right now the only work around is to modify the job file manually with a text editor. The jobs seem to build just fine. I have attached a job config file to show the issue. If I reduce the mapping down to 2974 bytes the error goes away and does not seem to return. My feeling is it is in the parser of the mapping, but that is a guess. For user login control we currently are using "Project-based Matrix Authorization Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12807) CVS plugin throwing Exception every time
Mark Trinh created JENKINS-12807: Summary: CVS plugin throwing Exception every time Key: JENKINS-12807 URL: https://issues.jenkins-ci.org/browse/JENKINS-12807 Project: Jenkins Issue Type: Bug Components: cvs Affects Versions: current Environment: SLES11 Reporter: Mark Trinh After using the cvs plugin to get changes, it's throwing an exception at the end and never passes. cvs rlog: Logging zlib/x64/Release FATAL: null java.lang.NullPointerException at hudson.scm.CVSSCM$3.buildFileList(CVSSCM.java:922) at hudson.scm.CVSSCM$3.invoke(CVSSCM.java:900) at hudson.scm.CVSSCM$3.invoke(CVSSCM.java:886) at hudson.FilePath.act(FilePath.java:758) at hudson.FilePath.act(FilePath.java:740) at hudson.scm.CVSSCM.getCvsFiles(CVSSCM.java:886) at hudson.scm.CVSSCM.calculateWorkspaceState(CVSSCM.java:869) at hudson.scm.CVSSCM.checkout(CVSSCM.java:836) at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:566) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:454) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11622) ChannelPinger fails while Free Swap Space checker is running on Windows Slaves
[
https://issues.jenkins-ci.org/browse/JENKINS-11622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159173#comment-159173
]
Sam Talebbeik commented on JENKINS-11622:
-
One more piece of information. This issue happened again the other day while
the target build slave server was cloning a repository. This means that the
build slave server was very busy doing I/O and cpu activities.
Could it be that the pinger's timeout is too short and too aggressive for
situations like this? If the network is very busy and if the target build slave
server is too busy with I/O and CPU activities then the response will not
travel fast enough from the main Jenkins server to the build slave server and
back from build slave server to the main Jenkins server.
> ChannelPinger fails while Free Swap Space checker is running on Windows Slaves
> --
>
> Key: JENKINS-11622
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11622
> Project: Jenkins
> Issue Type: Bug
> Components: core
> Environment: Windows Server 2003, 1 vCPU, 4GB RAM (32bit) 8GB RAM
> (64bit), 50GB virtual disk, VMware Hypervisor.
>Reporter: Ryan Hass
> Labels: channelpinger
>
> Windows slaves randomly disconnect while idle. This appears to be caused by
> free space threads which are stuck or still running, resulting in the SSH
> conenction being terminated and connections being reestablished.
> I am not exactly sure what the expected behavior is for the low-level
> handling and communication. However, at a high level, the expected behavior
> is for the slave connections to persist the channel pinger not to cause a
> reset.
> {noformat:title=jenkins.log}
> Nov 4, 2011 8:34:48 AM
> hudson.node_monitors.AbstractNodeMonitorDescriptor$Record
> WARNING: Previous Free Swap Space monitoring activity still in progress.
> Interrupting
> Nov 4, 2011 8:40:18 AM hudson.slaves.ChannelPinger$1 onDead
> INFO: Ping failed. Terminating the channel.
> Exception in thread "Monitoring w64-09 for Free Swap Space"
> hudson.remoting.RequestAbortedException: hudson.remotin
> g.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown
> at hudson.remoting.Request.call(Request.java:149)
> at hudson.remoting.Channel.call(Channel.java:660)
> at
> hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:83)
> at
> hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:81)
> at
> hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:202)
> Caused by: hudson.remoting.RequestAbortedException:
> hudson.remoting.Channel$OrderlyShutdown
> at hudson.remoting.Request.abort(Request.java:269)
> at hudson.remoting.Channel.terminate(Channel.java:711)
> at hudson.remoting.Channel$CloseCommand.execute(Channel.java:794)
> at hudson.remoting.Channel$ReaderThread.run(Channel.java:1024)
> Caused by: hudson.remoting.Channel$OrderlyShutdown
> ... 2 more
> Caused by: Command close created at
> at hudson.remoting.Command.(Command.java:62)
> at hudson.remoting.Command.(Command.java:47)
> at hudson.remoting.Channel$CloseCommand.(Channel.java:790)
> at hudson.remoting.Channel$CloseCommand.(Channel.java:790)
> at hudson.remoting.Channel.close(Channel.java:835)
> at hudson.remoting.Channel$CloseCommand.execute(Channel.java:793)
> ... 1 more
> Exception in thread "Monitoring w64-09 for Free Temp Space"
> hudson.remoting.RequestAbortedException: hudson.remotin
> g.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown
> at hudson.remoting.Request.call(Request.java:149)
> at hudson.remoting.Channel.call(Channel.java:660)
> at hudson.FilePath.act(FilePath.java:745)
> at hudson.FilePath.act(FilePath.java:738)
> at
> hudson.node_monitors.TemporarySpaceMonitor$1.getFreeSpace(TemporarySpaceMonitor.java:73)
> at
> hudson.node_monitors.DiskSpaceMonitorDescriptor.monitor(DiskSpaceMonitorDescriptor.java:135)
> at
> hudson.node_monitors.DiskSpaceMonitorDescriptor.monitor(DiskSpaceMonitorDescriptor.java:49)
> at
> hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:202)
> Caused by: hudson.remoting.RequestAbortedException:
> hudson.remoting.Channel$OrderlyShutdown
> at hudson.remoting.Request.abort(Request.java:269)
> at hudson.remoting.Channel.terminate(Channel.java:711)
> at hudson.remoting.Channel$CloseCommand.execute(Channel.java:794)
> at hudson.remoting.Channel$ReaderThread.run(Channel.java:1024)
> Caused by: hudson.remoting.Channel$OrderlyShutdown
> ... 2 more
[JIRA] (JENKINS-12808) cobertura-maven-plugin: cannot be deactivated + fails with NullPointerException + version 2.5.1 cannot be overwritten
Marco Schulze created JENKINS-12808: --- Summary: cobertura-maven-plugin: cannot be deactivated + fails with NullPointerException + version 2.5.1 cannot be overwritten Key: JENKINS-12808 URL: https://issues.jenkins-ci.org/browse/JENKINS-12808 Project: Jenkins Issue Type: Bug Components: cobertura Affects Versions: current Environment: Tested with Jenkins 1.451 Reporter: Marco Schulze Assignee: stephenconnolly Priority: Blocker There are three problems related to the cobertura-maven-plugin: 1) Even though my project does NOT have the cobertura-maven-plugin in its build/plugins-section, this maven-plugin is magically added by Jenkins to the build process. I did NOT enable any cobertura-related setting in the job, either. 2) The cobertura-maven-plugin causes the build to fail with a NullPointerException: Caused by: java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:472) at org.codehaus.mojo.cobertura.CoberturaReportMojo.getAllChildren(CoberturaReportMojo.java:574) at org.codehaus.mojo.cobertura.CoberturaReportMojo.executeAggregateReport(CoberturaReportMojo.java:275) at org.codehaus.mojo.cobertura.CoberturaReportMojo.executeAggregateReport(CoberturaReportMojo.java:265) at org.codehaus.mojo.cobertura.CoberturaReportMojo.executeReport(CoberturaReportMojo.java:251) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:93) ... 3) It seems to be impossible to override the version of the cobertura-maven-plugin: No matter what version I declare in my parent-POM's pluginManagement, Jenkins always uses version 2.5.1 For you to reproduce, I created a new project from scratch (I only copied some files from other projects and stripped most of their contents). Here are all the links: Project's SVN URL: https://dev.nightlabs.org/svn/public/main/experimentals/test20120216/ First build: https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/1/console This build has been done with cobertura-maven-plugin's version being set to 2.4 in my plugin-MANAGEMENT. Still the build on Jenkins uses version 2.5.1. Note, that the cobertura-maven-plugin is NOT listed in the plugins-section (but only in the pluginManagement). Therefore, it should not be included in the build process at all. When I run the build locally with "mvn clean install", it does not occur, too. Here's the log: https://dev.nightlabs.org/svn/public/main/experimentals/test20120216/org.nightlabs.test20120216.all/mvn_clean_install.ganesha.log Second build: https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/2/console This build has been done with the cobertura-maven-plugin being commented out from the pluginManagement. Now, the "Effective POM" in m2e shows me NO Cobertura AT ALL anymore and still the result is the same. 3rd and 4th build: I added configuration/skip=true in the parent-POM with the result that the build now works fine. But it does so only, because there is no unit test, yet (there is an *integration* test, but no *unit* test). 5th build: https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/5/console I added a unit test which produces this error in the log output (when being run the 2nd time): * Tests in error: doSomething(org.nightlabs.test20120216.client.test.SomeTest): org/nightlabs/test20120216/client/TestClient Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 [ERROR] There are test failures. * Despite this error, the build succeeds. However, this is not always the case: In another project, this is handled as a fatal error and breaks the build. I was not able to find out where's the difference. However, this 2nd test run should not happen at all in the first place. The problem is obviously that the cobertura-maven-plugin is correctly skipped (and thus does not instrument any class), but the unit-tests are still executed twice. And the second time, it tries to access instrumented classes, which do not exist. Here's what I did in Jenkins (version 1.451) to create the job (I did NOT enable any cobertura-related things!): => New Job ==> Job name = org.nightlabs.test20120216 ==> Build a maven2/3 project ==> OK ==> Enable project-based security ===> Read access for Anonymous ==> Source Code Management ===> Subversion CHECKED ===> Repository URL = https://dev.nightlabs.org/svn/public/main/experimentals/test20120216/ ===> Check-out Strategy = Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update' ==> Build ===> Root POM = org.nightlabs.test20120216.all/pom.xml ==> Save -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrato
[JIRA] (JENKINS-11622) ChannelPinger fails while Free Swap Space checker is running on Windows Slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-11622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159173#comment-159173 ] Sam Talebbeik edited comment on JENKINS-11622 at 2/16/12 8:05 PM: -- One more piece of information. This issue happened again the other day while the target build slave server was cloning a repository. This means that the build slave server was very busy doing I/O and cpu activities. Jenkins Log in jenkins.log file Feb 15, 2012 5:35:12 PM hudson.slaves.ChannelPinger$1 onDead INFO: Ping failed. Terminating the channel. Exception in thread "Monitoring slave-07 for Free Swap Space" hudson.remoting.RequestAbortedException: hud son.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:660) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:83) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:81) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java: 202) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.abort(Request.java:269) at hudson.remoting.Channel.terminate(Channel.java:711) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:794) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1024) Caused by: hudson.remoting.Channel$OrderlyShutdown ... 2 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:62) at hudson.remoting.Command.(Command.java:47) at hudson.remoting.Channel$CloseCommand.(Channel.java:790) at hudson.remoting.Channel$CloseCommand.(Channel.java:790) at hudson.remoting.Channel.close(Channel.java:835) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:793) ... 1 more Feb 15, 2012 5:35:12 PM hudson.model.AbstractBuild$AbstractRunner performAllBuildSteps WARNING: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception java.lang.NullPointerException at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:123) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:135) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:625) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:603) at hudson.model.Build$RunnerImpl.post2(Build.java:161) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:572) at hudson.model.Run.run(Run.java:1386) at hudson.matrix.MatrixRun.run(MatrixRun.java:137) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) Feb 15, 2012 5:35:53 PM hudson.slaves.SlaveComputer tryReconnect INFO: Attempting to reconnect slave-07 Build Job failure messages == FATAL: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:660) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) at $Proxy17.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:850) at hudson.Launcher$ProcStarter.join(Launcher.java:336) at hudson.plugins.mercurial.MercurialSCM.clone(MercurialSCM.java:577) at hudson.plugins.mercurial.MercurialSCM.checkout(MercurialSCM.java:422) at hudson.model.AbstractProject.checkout(AbstractProject.java:1174) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:523) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:418) at hudson.model.Run.run(Run.java:1362) at hudson.matrix.MatrixRun.run(MatrixRun.java:137) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$Orderl
[JIRA] (JENKINS-12808) cobertura-maven-plugin: cannot be deactivated + fails with NullPointerException + version 2.5.1 cannot be overwritten
[ https://issues.jenkins-ci.org/browse/JENKINS-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159174#comment-159174 ] Marco Schulze commented on JENKINS-12808: - I found out how to make the 2nd surefire-run (after the skipped cobertura-instrumentalisation) fail the whole build: https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/7/console If a method of a unit test returns an instance of a class that is located in the same project's src/main/java/, then surefire crashes when it tries to collect the test methods and the build breaks. > cobertura-maven-plugin: cannot be deactivated + fails with > NullPointerException + version 2.5.1 cannot be overwritten > - > > Key: JENKINS-12808 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12808 > Project: Jenkins > Issue Type: Bug > Components: cobertura >Affects Versions: current > Environment: Tested with Jenkins 1.451 >Reporter: Marco Schulze >Assignee: stephenconnolly >Priority: Blocker > > There are three problems related to the cobertura-maven-plugin: > 1) Even though my project does NOT have the cobertura-maven-plugin in its > build/plugins-section, this maven-plugin is magically added by Jenkins to the > build process. I did NOT enable any cobertura-related setting in the job, > either. > 2) The cobertura-maven-plugin causes the build to fail with a > NullPointerException: > Caused by: java.lang.NullPointerException > at java.util.ArrayList.addAll(ArrayList.java:472) > at > org.codehaus.mojo.cobertura.CoberturaReportMojo.getAllChildren(CoberturaReportMojo.java:574) > at > org.codehaus.mojo.cobertura.CoberturaReportMojo.executeAggregateReport(CoberturaReportMojo.java:275) > at > org.codehaus.mojo.cobertura.CoberturaReportMojo.executeAggregateReport(CoberturaReportMojo.java:265) > at > org.codehaus.mojo.cobertura.CoberturaReportMojo.executeReport(CoberturaReportMojo.java:251) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:93) > ... > 3) It seems to be impossible to override the version of the > cobertura-maven-plugin: No matter what version I declare in my parent-POM's > pluginManagement, Jenkins always uses version 2.5.1 > For you to reproduce, I created a new project from scratch (I only copied > some files from other projects and stripped most of their contents). Here are > all the links: > Project's SVN URL: > https://dev.nightlabs.org/svn/public/main/experimentals/test20120216/ > First build: > https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/1/console > This build has been done with cobertura-maven-plugin's version being set to > 2.4 in my plugin-MANAGEMENT. Still the build on Jenkins uses version 2.5.1. > Note, that the cobertura-maven-plugin is NOT listed in the plugins-section > (but only in the pluginManagement). Therefore, it should not be included in > the build process at all. When I run the build locally with "mvn clean > install", it does not occur, too. Here's the log: > https://dev.nightlabs.org/svn/public/main/experimentals/test20120216/org.nightlabs.test20120216.all/mvn_clean_install.ganesha.log > Second build: > https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/2/console > This build has been done with the cobertura-maven-plugin being commented out > from the pluginManagement. Now, the "Effective POM" in m2e shows me NO > Cobertura AT ALL anymore and still the result is the same. > 3rd and 4th build: > I added configuration/skip=true in the parent-POM with the result that the > build now works fine. But it does so only, because there is no unit test, yet > (there is an *integration* test, but no *unit* test). > 5th build: > https://dev.nightlabs.org/jenkins/job/org.nightlabs.test20120216/5/console > I added a unit test which produces this error in the log output (when being > run the 2nd time): > * > Tests in error: > doSomething(org.nightlabs.test20120216.client.test.SomeTest): > org/nightlabs/test20120216/client/TestClient > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > [ERROR] There are test failures. > * > Despite this error, the build succeeds. However, this is not always the case: > In another project, this is handled as a fatal error and breaks the build. I > was not able to find out where's the difference. However, this 2nd test run > should not happen at all in the first place. > The problem is obviously that the cobertura-maven-plugin is correctly skipped > (and thus does not instrument any class), but the unit-tests are still > executed twice. And the second time, it tries to access instrumented classes, > which
[JIRA] (JENKINS-12809) Injecting from file removes backslashes on ${WORKSPACE}
pixman20 created JENKINS-12809:
--
Summary: Injecting from file removes backslashes on ${WORKSPACE}
Key: JENKINS-12809
URL: https://issues.jenkins-ci.org/browse/JENKINS-12809
Project: Jenkins
Issue Type: Bug
Components: envinject
Affects Versions: current
Environment: Windows Server 2003
Reporter: pixman20
Assignee: gbois
Priority: Critical
When using a configuration file, ${WORKSPACE} cannot be used if it contains
backslashes.
Obviously this causes a critical issue on Windows.
When using the content section it works fine.
Output shown in the "Injected Environment Variables" Page:
AAACONTENTVAR D:\jenkins\jobs\TEST_FAIL\workspace
AAAFILEVAR D:jenkinsjobsTEST_FAILworkspace
This behavior can be reproduced by doing the following:
1) Add build step "Execute batch script" and add the following content:
echo AAAFILEVAR=${WORKSPACE} > temp.config
2) Add build step "Inject environment variables" and add to properties file
path:
temp.config
3) Add build step "Inject environment variables" and add to properties content:
AAACONTENTVAR=${WORKSPACE}
4) Add build step "Execute batch script" and add the following content:
@ECHO OFF
echo AAAFILEVAR= %AAAFILEVAR%
echo AAACONTENTVAR = %AAACONTENTVAR%
Console output:
--
Building on master in workspace D:\jenkins\jobs\TEST_FAIL\workspace
[workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson6646008055064848449.bat
D:\jenkins\jobs\TEST_FAIL\workspace>echo AAAFILEVAR=${WORKSPACE} 1>temp.config
D:\jenkins\jobs\TEST_FAIL\workspace>exit 0
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties file path
'temp.config'
[EnvInject] - Variables injected successfully.
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties content
AAACONTENTVAR=${WORKSPACE}
[EnvInject] - Variables injected successfully.
[workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson7725197076031217954.bat
AAAFILEVAR= D:jenkinsjobsTEST_FAILworkspace
AAACONTENTVAR = D:\jenkins\jobs\TEST_FAIL\workspace
Finished: SUCCESS
--
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12809) Injecting from file removes backslashes on ${WORKSPACE}
[
https://issues.jenkins-ci.org/browse/JENKINS-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159175#comment-159175
]
pixman20 commented on JENKINS-12809:
The current workaround appears to be manually defining a custom workspace with
/s.
> Injecting from file removes backslashes on ${WORKSPACE}
> ---
>
> Key: JENKINS-12809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12809
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
> Environment: Windows Server 2003
>Reporter: pixman20
>Assignee: gbois
>Priority: Critical
>
> When using a configuration file, ${WORKSPACE} cannot be used if it contains
> backslashes.
> Obviously this causes a critical issue on Windows.
> When using the content section it works fine.
> Output shown in the "Injected Environment Variables" Page:
> AAACONTENTVAR D:\jenkins\jobs\TEST_FAIL\workspace
> AAAFILEVARD:jenkinsjobsTEST_FAILworkspace
> This behavior can be reproduced by doing the following:
> 1) Add build step "Execute batch script" and add the following content:
>echo AAAFILEVAR=${WORKSPACE} > temp.config
> 2) Add build step "Inject environment variables" and add to properties file
> path:
>temp.config
> 3) Add build step "Inject environment variables" and add to properties
> content:
>AAACONTENTVAR=${WORKSPACE}
> 4) Add build step "Execute batch script" and add the following content:
>@ECHO OFF
>echo AAAFILEVAR= %AAAFILEVAR%
>echo AAACONTENTVAR = %AAACONTENTVAR%
> Console output:
> --
> Building on master in workspace D:\jenkins\jobs\TEST_FAIL\workspace
> [workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson6646008055064848449.bat
> D:\jenkins\jobs\TEST_FAIL\workspace>echo AAAFILEVAR=${WORKSPACE}
> 1>temp.config
> D:\jenkins\jobs\TEST_FAIL\workspace>exit 0
> [EnvInject] - Injecting environment variables from a build step.
> [EnvInject] - Injecting as environment variables the properties file path
> 'temp.config'
> [EnvInject] - Variables injected successfully.
> [EnvInject] - Injecting environment variables from a build step.
> [EnvInject] - Injecting as environment variables the properties content
> AAACONTENTVAR=${WORKSPACE}
> [EnvInject] - Variables injected successfully.
> [workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson7725197076031217954.bat
> AAAFILEVAR= D:jenkinsjobsTEST_FAILworkspace
> AAACONTENTVAR = D:\jenkins\jobs\TEST_FAIL\workspace
> Finished: SUCCESS
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159176#comment-159176 ] Mike Henderson commented on JENKINS-12806: -- If I remove security by allowing everyone to do anything the bug changes to showing a parsing error in the workspace mapping at the line where it flows over 2975 bytes. This error does not seem to effect the job itself and the entire workspace is synced just fine. I hope that helps to pinpoint the issue. > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
Vignesh Senapathy created JENKINS-12810: --- Summary: JUnit test results are getting wrongly attached to all the test cases Key: JENKINS-12810 URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 Project: Jenkins Issue Type: Bug Components: testlink Affects Versions: current Reporter: Vignesh Senapathy Assignee: Bruno P. Kinoshita Fix For: current Attachments: last_tc.png, tc1.png, tc2.png Hi, I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the Junit Test results are getting generated. This in turn calls the Testlink xml rpc and attaches the results to the test case, but the test results are attached wrongly. The 1st test case has 6 results, the next has 5 and so on and the last one has 1 test result attached to it. I dont know if it is bug which is causing this. Please let me know what seems to be the problems. Also the execution flags are correctly rendered in this. which ever test case fails is marked as failed and which passed is marked as passed. Also I have one custom field which maps to the test suite name and test classname. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12811) Pick the default resolution for the target when none is specified
Jørgen Tjernø created JENKINS-12811: --- Summary: Pick the default resolution for the target when none is specified Key: JENKINS-12811 URL: https://issues.jenkins-ci.org/browse/JENKINS-12811 Project: Jenkins Issue Type: New Feature Components: android-emulator Reporter: Jørgen Tjernø Assignee: Christopher Orr -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12811) Pick the default resolution for the target when none is specified
[ https://issues.jenkins-ci.org/browse/JENKINS-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159177#comment-159177 ] Christopher Orr commented on JENKINS-12811: --- Default skin (i.e. resolution) is determined by getDefaultSkin() method in: platform/sdk/sdkmanager/libs/sdklib/src/com/android/sdklib/PlatformTarget.java Default skin for an add-on is inherited from the platform it depends on. > Pick the default resolution for the target when none is specified > - > > Key: JENKINS-12811 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12811 > Project: Jenkins > Issue Type: New Feature > Components: android-emulator >Reporter: Jørgen Tjernø >Assignee: Christopher Orr > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1144) email-ext plugin causes NullPointerException when sending email for successful build
[ https://issues.jenkins-ci.org/browse/JENKINS-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159178#comment-159178 ] Nitesh Shakya commented on JENKINS-1144: I am using a new version of jenkins and still have similar issue. I am getting following errors: Sending email for trigger: Success ERROR: Could not send email as a part of the post-build publishers. java.lang.NullPointerException at java.util.regex.Matcher.quoteReplacement(Unknown Source) at hudson.plugins.emailext.plugins.ContentBuilder.transformText(ContentBuilder.java:65) at hudson.plugins.emailext.ExtendedEmailPublisher.setSubject(ExtendedEmailPublisher.java:453) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:307) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:255) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:247) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:207) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653) at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) at hudson.model.Run.run(Run.java:1453) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Finished: SUCCESS I dont get an error when using test email > email-ext plugin causes NullPointerException when sending email for > successful build > > > Key: JENKINS-1144 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1144 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Platform: All, OS: Linux >Reporter: brad_c >Assignee: kdsweeney > > I have Hudson 1.146 and email-ext 1.2 installed. I previously had email > notifications working for my job using the email config provided by Hudson. > I configured the email-ext plugin to send emails on successful builds, but an > NPE is thrown in the hudson.Util.encode() method when it attempts to send the > email. > I tried this with the option for "E-mail Notification" checked and with it > unchecked, and the NPE occurred for both scenarios. > Here is the output from my job ( the email address was xxx'ed out ) > - > BUILD SUCCESSFUL > Total time: 2 minutes 25 seconds > Recording fingerprints > Recording test results > Sending e-mails to: x...@xxx.com > FATAL: null > java.lang.NullPointerException > at hudson.Util.encode(Util.java:400) > at > hudson.plugins.emailext.ExtendedEmailPublisher.transformText(ExtendedEmailPublisher.java:244) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:195) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:167) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:155) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:124) > at hudson.model.Build$RunnerImpl.post2(Build.java:138) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:244) > at hudson.model.Run.run(Run.java:597) > at hudson.model.Build.run(Build.java:103) > at hudson.model.ResourceController.execute(ResourceController.java:66) > at hudson.model.Executor.run(Executor.java:62) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1144) email-ext plugin causes NullPointerException when sending email for successful build
[ https://issues.jenkins-ci.org/browse/JENKINS-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159179#comment-159179 ] Nitesh Shakya commented on JENKINS-1144: I have following specification details Jenkins war org.jenkins-ci.main:jenkins-war:1.451 Jenkins Email Extension Plugin This plugin is a replacement for Jenkins's email publisher 2.18 Sorry for not writing it in my previous comment > email-ext plugin causes NullPointerException when sending email for > successful build > > > Key: JENKINS-1144 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1144 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Platform: All, OS: Linux >Reporter: brad_c >Assignee: kdsweeney > > I have Hudson 1.146 and email-ext 1.2 installed. I previously had email > notifications working for my job using the email config provided by Hudson. > I configured the email-ext plugin to send emails on successful builds, but an > NPE is thrown in the hudson.Util.encode() method when it attempts to send the > email. > I tried this with the option for "E-mail Notification" checked and with it > unchecked, and the NPE occurred for both scenarios. > Here is the output from my job ( the email address was xxx'ed out ) > - > BUILD SUCCESSFUL > Total time: 2 minutes 25 seconds > Recording fingerprints > Recording test results > Sending e-mails to: x...@xxx.com > FATAL: null > java.lang.NullPointerException > at hudson.Util.encode(Util.java:400) > at > hudson.plugins.emailext.ExtendedEmailPublisher.transformText(ExtendedEmailPublisher.java:244) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:195) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:167) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:155) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:124) > at hudson.model.Build$RunnerImpl.post2(Build.java:138) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:244) > at hudson.model.Run.run(Run.java:597) > at hudson.model.Build.run(Build.java:103) > at hudson.model.ResourceController.execute(ResourceController.java:66) > at hudson.model.Executor.run(Executor.java:62) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1144) email-ext plugin causes NullPointerException when sending email for successful build
[ https://issues.jenkins-ci.org/browse/JENKINS-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitesh Shakya reopened JENKINS-1144: Assignee: abayer (was: kdsweeney) I am having similar issue again can you help me? > email-ext plugin causes NullPointerException when sending email for > successful build > > > Key: JENKINS-1144 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1144 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Platform: All, OS: Linux >Reporter: brad_c >Assignee: abayer > > I have Hudson 1.146 and email-ext 1.2 installed. I previously had email > notifications working for my job using the email config provided by Hudson. > I configured the email-ext plugin to send emails on successful builds, but an > NPE is thrown in the hudson.Util.encode() method when it attempts to send the > email. > I tried this with the option for "E-mail Notification" checked and with it > unchecked, and the NPE occurred for both scenarios. > Here is the output from my job ( the email address was xxx'ed out ) > - > BUILD SUCCESSFUL > Total time: 2 minutes 25 seconds > Recording fingerprints > Recording test results > Sending e-mails to: x...@xxx.com > FATAL: null > java.lang.NullPointerException > at hudson.Util.encode(Util.java:400) > at > hudson.plugins.emailext.ExtendedEmailPublisher.transformText(ExtendedEmailPublisher.java:244) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:195) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:167) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:155) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:124) > at hudson.model.Build$RunnerImpl.post2(Build.java:138) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:244) > at hudson.model.Run.run(Run.java:597) > at hudson.model.Build.run(Build.java:103) > at hudson.model.ResourceController.execute(ResourceController.java:66) > at hudson.model.Executor.run(Executor.java:62) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12812) dryRun switch failes
domi created JENKINS-12812: -- Summary: dryRun switch failes Key: JENKINS-12812 URL: https://issues.jenkins-ci.org/browse/JENKINS-12812 Project: Jenkins Issue Type: Bug Components: m2release Environment: m2release 0.9.0 Reporter: domi Assignee: teilo triggering a release build with the dryRun checkbox checked failes because release:perform does not support the dryRun flag. I have already opened a feature request for the maven-release-plugin: https://jira.codehaus.org/browse/MRELEASE-736 ...but I will also work on a fix in the jenkins m2release plugin asap to get this issue sorted for all versions of the maven-release-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-10127) M2 Release plugin ignores parameters from a parameterized build
[ https://issues.jenkins-ci.org/browse/JENKINS-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] domi resolved JENKINS-10127. Resolution: Fixed > M2 Release plugin ignores parameters from a parameterized build > --- > > Key: JENKINS-10127 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10127 > Project: Jenkins > Issue Type: Bug > Components: m2release >Affects Versions: current >Reporter: Piers Geyman >Assignee: teilo >Priority: Critical > > We have parameterized build tasks where we specify the branch part of our svn > repository so we can build from the trunk or a branch. > This plugin does not allow us to specify this parameter and so always does a > checkout from the trunk (trunk is the default value for the parameter). > This means that we cannot release from a branch. > Please fix this so that parameters can be specified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12812) dryRun switch failes
[ https://issues.jenkins-ci.org/browse/JENKINS-12812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] domi reassigned JENKINS-12812: -- Assignee: domi (was: teilo) > dryRun switch failes > > > Key: JENKINS-12812 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12812 > Project: Jenkins > Issue Type: Bug > Components: m2release > Environment: m2release 0.9.0 >Reporter: domi >Assignee: domi > > triggering a release build with the dryRun checkbox checked failes because > release:perform does not support the dryRun flag. > I have already opened a feature request for the maven-release-plugin: > https://jira.codehaus.org/browse/MRELEASE-736 > ...but I will also work on a fix in the jenkins m2release plugin asap to get > this issue sorted for all versions of the maven-release-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-4690) Be able to arbitrary paramterize m2 releases
[ https://issues.jenkins-ci.org/browse/JENKINS-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] domi resolved JENKINS-4690. --- Resolution: Fixed > Be able to arbitrary paramterize m2 releases > > > Key: JENKINS-4690 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4690 > Project: Jenkins > Issue Type: Improvement > Components: m2release >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: davidkarlsen >Assignee: teilo > > be able to provide arbitrary parameters to the maven release command line. > (not > merely versions like today). > Suggestion: > Configure it like release:prepare release:perform -Dusername=%USERNAME% > -Dpassword=%PASSWORD% -DreleaseVersion=%RELEASEVERSION% > -DdevelopmentVersion=%DEVELOPMENTVERSOIN% - or some other type of > placeholders. > This should lead you into a dialogue where you're prompted for username, pw, > rel > ver, and dev. ver for the release. > This way you won't have to hardcode credentials into the hudson job > configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4500) Make it possible to select a node to do the release on
[ https://issues.jenkins-ci.org/browse/JENKINS-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] domi resolved JENKINS-4500. --- Resolution: Fixed > Make it possible to select a node to do the release on > -- > > Key: JENKINS-4500 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4500 > Project: Jenkins > Issue Type: Improvement > Components: m2release >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: redsolo >Assignee: teilo >Priority: Minor > > With my hudson.ramfelt.se server, i have several nodes contributed by > different > persons and some of them are not properly setuped for releasing hudson > plugins. > ie, they havent added the subversion credentials to the subversion cache (not > Hudson's svn credentials). To do that the user must run "svn -list > https://hudson..."; (as discussed at http://wiki.hudson- > ci.org/display/JENKINS/Hosting+Plugins) > I have jobs that are being built by two nodes, but it is only one that I know > have done the "svn -list". Therefore I would like to specify what node I want > the release to be done on. Also, I would like to be certain that it will be > released by a specific user and not the user that is running the node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12813) Resolving variable that does not exist
Jason May created JENKINS-12813: --- Summary: Resolving variable that does not exist Key: JENKINS-12813 URL: https://issues.jenkins-ci.org/browse/JENKINS-12813 Project: Jenkins Issue Type: Improvement Components: description-setter Affects Versions: current Environment: Any Version of Jenkins, version 1.0 of Description Setter plugin Reporter: Jason May Assignee: huybrechts When setting a job description from a file in the workspace, and the file contains a variable (i.e. $MYVAR) that does not exist, would be much better to not error and fail the build, but rather log out the error and mark the build as passed. Could set a boolean flag like "fail build on error" that could have the behavior so the current behavior could be kept as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12788) Missing variables when executing EnvInject script
[ https://issues.jenkins-ci.org/browse/JENKINS-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159181#comment-159181 ] SCM/JIRA link daemon commented on JENKINS-12788: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/envinject/EnvInjectListener.java http://jenkins-ci.org/commit/envinject-plugin/f2b3a4921b5127718214ad0454bb55a3812dbcfb Log: Fix JENKINS-12788 > Missing variables when executing EnvInject script > - > > Key: JENKINS-12788 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12788 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins 1.450 on Ubuntu 10.04 > EnvInject 1.20 or 1.22 >Reporter: Patrick Hartling >Assignee: gbois > Labels: git, plugin, windows > Attachments: config.xml, config.xml > > > Not all the Jenkins environment variables and build variables are being made > available to the EnvInject script. When testing with version 1.19, we had > JOB_NAME, EXECUTOR_NUMBER, and GIT_BRANCH to name a few. With 1.20 and 1.22, > we still have JOB_NAME, but EXECUTOR_NUMBER and GIT_BRANCH are not available. > I have attached a config.xml for use on a Windows slave. The same issue > exists on a Linux slave. The Git repository referenced in the config.xml > could be anything. The repository referenced is just there so that there is > some Git-related piece in the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12788) Missing variables when executing EnvInject script
[ https://issues.jenkins-ci.org/browse/JENKINS-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-12788. - Resolution: Fixed > Missing variables when executing EnvInject script > - > > Key: JENKINS-12788 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12788 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current > Environment: Jenkins 1.450 on Ubuntu 10.04 > EnvInject 1.20 or 1.22 >Reporter: Patrick Hartling >Assignee: gbois > Labels: git, plugin, windows > Attachments: config.xml, config.xml > > > Not all the Jenkins environment variables and build variables are being made > available to the EnvInject script. When testing with version 1.19, we had > JOB_NAME, EXECUTOR_NUMBER, and GIT_BRANCH to name a few. With 1.20 and 1.22, > we still have JOB_NAME, but EXECUTOR_NUMBER and GIT_BRANCH are not available. > I have attached a config.xml for use on a Windows slave. The same issue > exists on a Linux slave. The Git repository referenced in the config.xml > could be anything. The repository referenced is just there so that there is > some Git-related piece in the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11926) Warnings plugin does not work on a slave
[ https://issues.jenkins-ci.org/browse/JENKINS-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159182#comment-159182 ] torbent commented on JENKINS-11926: --- Wild guesses; maybe helpful, maybe confusing: * Permission problem? Is the log file readable on the slave by the user that runs the Jenkins service? * In our setup, the workspaces are on network drives and reachable from both master and slave (although not at identical paths). Could it be that both server and slave need access to the workspace for dynamic warnings parsing to work? * Or perhaps the expression just doesn't match? For example I'd guess that $5 is wrong (should probably be (.*)). Does the dynamic parser expect to be able to match a whole line? * Did you happen to forget restarting Jenkins after installing Warnings 3.27? Hope this helps. My very similar JENKINS-12280 issue seems to be solved by version 3.27 (a little extra test is still pending). > Warnings plugin does not work on a slave > > > Key: JENKINS-11926 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11926 > Project: Jenkins > Issue Type: Bug > Components: warnings >Affects Versions: current > Environment: Tried both with: > - a windows master, and a linux slave. Jenkins 1.440 Warnings 3.24 > - a linux box (different from the above) acting both as master and slave, > Jenkins 1.440, Warnings 3.24 >Reporter: Massimo Rossello >Assignee: Ulli Hafner > Labels: plugin, slave, warnings > Attachments: issue11926.txt > > > I create my own parser. If I use the Warning parsing on the master it works > as expected. If I make the parsing on the slave it always reports 0 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7733) System Message - Doesnt appear on any view other than the default view
[ https://issues.jenkins-ci.org/browse/JENKINS-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159183#comment-159183 ] dogfood commented on JENKINS-7733: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1533|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1533/] [FIXED JENKINS-7733] System Message - Doesnt appear on any view other (Revision f469733fbaa60cb93d92eed5842df46c5e1edb0c) changelog for JENKINS-7733 (Revision 546157701b2b95ff8232c01e62e7476cd16003fa) [FIXED JENKINS-7733] reimplementation of JENKINS-7733. (Revision 875b3f628b9127661a3b84945df30bcaf66f3534) Result = SUCCESS Seiji Sogabe : [f469733fbaa60cb93d92eed5842df46c5e1edb0c|https://github.com/jenkinsci/jenkins/commit/f469733fbaa60cb93d92eed5842df46c5e1edb0c] Files : * core/src/main/resources/lib/hudson/editableDescription.jelly * core/src/main/java/hudson/model/View.java * core/src/main/java/hudson/model/TreeView.java * core/src/main/java/hudson/model/MyViewsProperty.java * core/src/main/java/hudson/model/ViewGroup.java Seiji Sogabe : [546157701b2b95ff8232c01e62e7476cd16003fa|https://github.com/jenkinsci/jenkins/commit/546157701b2b95ff8232c01e62e7476cd16003fa] Files : * changelog.html Seiji Sogabe : [875b3f628b9127661a3b84945df30bcaf66f3534|https://github.com/jenkinsci/jenkins/commit/875b3f628b9127661a3b84945df30bcaf66f3534] Files : * core/src/main/java/hudson/model/ViewGroup.java * core/src/main/resources/lib/hudson/editableDescription.jelly * core/src/main/java/hudson/model/TreeView.java * core/src/main/java/hudson/model/View.java * core/src/main/java/hudson/model/MyViewsProperty.java > System Message - Doesnt appear on any view other than the default view > -- > > Key: JENKINS-7733 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7733 > Project: Jenkins > Issue Type: Improvement > Components: gui >Affects Versions: current >Reporter: saimad >Assignee: sogabe >Priority: Minor > Fix For: current > > Attachments: SystemMessage_NG.png, SystemMessage_OK.png > > > System Message Configured to be : "Official Hudson Server" > This message appears only in the default "All" view. Once you click on any > other view, the message is not displayed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[
https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159184#comment-159184
]
Richard Mortimer commented on JENKINS-12037:
I'm still max'd out with $dayjob and have not had time to look in much detail
at this.
I just did a quick test on my test system with 1.451 using tomcat 6 and do not
see any timeouts there with the tomcat http data upload timeout set to 20
seconds. That rules out any basic brokenness (I hope!).
Looking at your log files (see below) there is one instance where an error
occurs 12 seconds after the previous timeout. That suggests that tomcat 7 is
timing out in around 10 seconds. The jenkins channel keepalive ping is set for
15 seconds so it could be that the ping is still not aggressive enough.
We probably just need to test with a 5 seconds ping time and see if that fixes
things.
First error reported in ConsoleOutput.log
{code}
Feb 6, 2012 2:47:38 PM hudson.remoting.Channel$ReaderThread run
SEVERE: I/O error in channel Chunked connection to
http://99.99.99.94:8082/jenkins/cli
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133)
Caused by: java.io.EOFException
{code}
This corresponds to the following two connections in
localhost_access_log.2012-02-06.txt
{code}
10.25.50.94 - - [06/Feb/2012:14:47:38 -0500] "POST /jenkins/cli HTTP/1.1" 200
13935
10.25.50.94 - - [06/Feb/2012:14:47:38 -0500] "POST /jenkins/cli HTTP/1.1" 200 -
{code}
The former is the downstream link and the latter is the upstream (sending from
cli to jenkins) hence there being no output in that direction.
catalina.out (equivalent to standalone jenkins.log) has the other side of the
error
This confirms that the upstream reader sees the input data closed by tomcat.
{code}
Feb 6, 2012 2:47:38 PM hudson.remoting.Channel$ReaderThread run
SEVERE: I/O error in channel HTTP full-duplex channel
b625b58a-d9d7-4a42-856c-287e953edb47
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
{code}
The next error in the console output occurs 12 seconds later.
{code}
Feb 6, 2012 2:48:00 PM hudson.remoting.Channel$ReaderThread run
SEVERE: I/O error in channel Chunked connection to
http://99.99.99.94:8082/jenkins/cli
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133)
{code}
{code}
10.25.50.94 - - [06/Feb/2012:14:48:00 -0500] "POST /jenkins/cli HTTP/1.1" 200
13935
10.25.50.94 - - [06/Feb/2012:14:48:00 -0500] "POST /jenkins/cli HTTP/1.1" 200 -
{code}
The access log has a couple of extra cli commands in the meantime. It isn't
clear whether these are for the same job or for something else. Assuming they
are for something else that means that the 2nd command timed out roughly 10
seconds after the previous cli command.
{code}
10.25.50.94 - - [06/Feb/2012:14:47:39 -0500] "POST /jenkins/cli HTTP/1.1" 200
10156
10.25.50.94 - - [06/Feb/2012:14:47:39 -0500] "POST /jenkins/cli HTTP/1.1" 200 -
10.25.50.94 - - [06/Feb/2012:14:47:39 -0500] "POST /jenkins/cli HTTP/1.1" 200
10156
10.25.50.94 - - [06/Feb/2012:14:47:39 -0500] "POST /jenkins/cli HTTP/1.1" 200 -
{code}
I wonder if the http data upload inactivity timeout is 10 seconds in tomcat7.
> CLI - I/O error in channel Chunked connection/Unexpected termination of the
> channel - still occurring in Jenkins 1.449
> --
>
> Key: JENKINS-12037
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12037
> Project: Jenkins
> Issue Type: Bug
> Components: cli
> Environment: * Running on SLES9 Linux server with 4 CPUs and plenty
> of diskspace.
> * Tomcat 7.0.22
> * JDK 1.6.0_14
> * Only ONE Master configuration - no slaves are configured
> * 3 Executors - (one less than the max number of CPUs)
>Reporter: mark streit
> Attachments: Tomcat7_Jenkins1449_logs.zip
>
>
> We reported an issue some time back that was also listed as fixed in Jenkins
> 1.441:
> Log:
> [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when
> using jenkins-cli.jar
> Perhaps another bug should NOT be submitted so I have added the following
> comments below the line to the original defect 11130 comments section in case
> it can be reviewed/re-opened.
> We did NOT try to make any adjustments to the Tomcat configuration:
> Tomcat Connector connectionUploadTimeout
> but we are also now seeing the same problem with Winstone when at this same
> 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR
> at 1.441 running in Winstone) and that is serving asthe current workaround.
>
[JIRA] (JENKINS-12814) CLI doesn't support upgrading Jenkins itself
apgray created JENKINS-12814: Summary: CLI doesn't support upgrading Jenkins itself Key: JENKINS-12814 URL: https://issues.jenkins-ci.org/browse/JENKINS-12814 Project: Jenkins Issue Type: Bug Components: cli Affects Versions: current Reporter: apgray Fix For: current -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12809) Injecting from file removes backslashes on ${WORKSPACE}
[
https://issues.jenkins-ci.org/browse/JENKINS-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gbois closed JENKINS-12809.
---
Resolution: Not A Defect
I think the problem is due to this action
echo AAAFILEVAR=${WORKSPACE} > temp.config
If you look at the temp.config file content, backslash are missing.
Therefore, EnvInject is not in charge to fix it.
Do not hesitate to reopen the issue if I'm wrong
> Injecting from file removes backslashes on ${WORKSPACE}
> ---
>
> Key: JENKINS-12809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12809
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
> Environment: Windows Server 2003
>Reporter: pixman20
>Assignee: gbois
>Priority: Critical
>
> When using a configuration file, ${WORKSPACE} cannot be used if it contains
> backslashes.
> Obviously this causes a critical issue on Windows.
> When using the content section it works fine.
> Output shown in the "Injected Environment Variables" Page:
> AAACONTENTVAR D:\jenkins\jobs\TEST_FAIL\workspace
> AAAFILEVARD:jenkinsjobsTEST_FAILworkspace
> This behavior can be reproduced by doing the following:
> 1) Add build step "Execute batch script" and add the following content:
>echo AAAFILEVAR=${WORKSPACE} > temp.config
> 2) Add build step "Inject environment variables" and add to properties file
> path:
>temp.config
> 3) Add build step "Inject environment variables" and add to properties
> content:
>AAACONTENTVAR=${WORKSPACE}
> 4) Add build step "Execute batch script" and add the following content:
>@ECHO OFF
>echo AAAFILEVAR= %AAAFILEVAR%
>echo AAACONTENTVAR = %AAACONTENTVAR%
> Console output:
> --
> Building on master in workspace D:\jenkins\jobs\TEST_FAIL\workspace
> [workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson6646008055064848449.bat
> D:\jenkins\jobs\TEST_FAIL\workspace>echo AAAFILEVAR=${WORKSPACE}
> 1>temp.config
> D:\jenkins\jobs\TEST_FAIL\workspace>exit 0
> [EnvInject] - Injecting environment variables from a build step.
> [EnvInject] - Injecting as environment variables the properties file path
> 'temp.config'
> [EnvInject] - Variables injected successfully.
> [EnvInject] - Injecting environment variables from a build step.
> [EnvInject] - Injecting as environment variables the properties content
> AAACONTENTVAR=${WORKSPACE}
> [EnvInject] - Variables injected successfully.
> [workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson7725197076031217954.bat
> AAAFILEVAR= D:jenkinsjobsTEST_FAILworkspace
> AAACONTENTVAR = D:\jenkins\jobs\TEST_FAIL\workspace
> Finished: SUCCESS
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12742) XML Reader feature
[
https://issues.jenkins-ci.org/browse/JENKINS-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159186#comment-159186
]
Joshua Niehus commented on JENKINS-12742:
-
I extended the token macro plugin on my fork to include this:
https://github.com/jniehus/token-macro-plugin
Im sure I violated many laws from the Kingdom of nouns but it seems to work.
Use as requested:
${XML, file="pom.xml", xpath="/project/version/text()"} -> 1.6-SNAPSHOT
I dont like to kill jobs for simple mistakes or in cases where to token value
is used in a trivial way so I passed off most of the errors into the token's
string.
*For example, the token will read 'XML not well formed' on files where the xml
is missing a node/endNode.
*In the event your xpath expression catches more that one value, the token
string will become a semicolon separated string of all the values...
*For erroneous xpath expressions, i set the token to read as 'Error reading
. is probably messed up
> XML Reader feature
> --
>
> Key: JENKINS-12742
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12742
> Project: Jenkins
> Issue Type: New Feature
> Components: token-macro
>Reporter: Eugene Gligalov
>Assignee: Kohsuke Kawaguchi
>
> Hi,
> Would be nice if plugin has possibility to read xml using xpath, this might
> be useful for reading version from maven pom.xml it might look like:
> ${PROPFILE,file="somepath/pom.xml",xpath="/project/version/text()"}
> Regards
> Eugene Gligalov
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12742) XML Reader feature
[
https://issues.jenkins-ci.org/browse/JENKINS-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159186#comment-159186
]
Joshua Niehus edited comment on JENKINS-12742 at 2/17/12 12:06 AM:
---
I extended the token macro plugin on my fork to include this:
https://github.com/jniehus/token-macro-plugin
Im sure I violated many laws from the Kingdom of nouns but it seems to work.
Use as requested:
${XML, file="pom.xml", xpath="/project/version/text()"} -> 1.6-SNAPSHOT
I dont like to kill jobs for simple mistakes or in cases where to token value
is used in a trivial way so I passed off most of the errors into the token's
string.
*For example, the token will read 'XML not well formed' on files where the xml
is missing a node/endNode.
*In the event your xpath expression catches more that one value, the token
string will become a semicolon separated string of all the values...
*For erroneous xpath expressions, i set the token to read as 'Error reading
. is probably messed up'.
was (Author: joshua_niehus):
I extended the token macro plugin on my fork to include this:
https://github.com/jniehus/token-macro-plugin
Im sure I violated many laws from the Kingdom of nouns but it seems to work.
Use as requested:
${XML, file="pom.xml", xpath="/project/version/text()"} -> 1.6-SNAPSHOT
I dont like to kill jobs for simple mistakes or in cases where to token value
is used in a trivial way so I passed off most of the errors into the token's
string.
*For example, the token will read 'XML not well formed' on files where the xml
is missing a node/endNode.
*In the event your xpath expression catches more that one value, the token
string will become a semicolon separated string of all the values...
*For erroneous xpath expressions, i set the token to read as 'Error reading
. is probably messed up
> XML Reader feature
> --
>
> Key: JENKINS-12742
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12742
> Project: Jenkins
> Issue Type: New Feature
> Components: token-macro
>Reporter: Eugene Gligalov
>Assignee: Kohsuke Kawaguchi
>
> Hi,
> Would be nice if plugin has possibility to read xml using xpath, this might
> be useful for reading version from maven pom.xml it might look like:
> ${PROPFILE,file="somepath/pom.xml",xpath="/project/version/text()"}
> Regards
> Eugene Gligalov
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159187#comment-159187 ] Rob Petti commented on JENKINS-12806: - Can you post the parsing error? > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti updated JENKINS-12806: Assignee: Rob Petti > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson >Assignee: Rob Petti > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159188#comment-159188 ] Mike Henderson commented on JENKINS-12806: -- I get a "Invalid mapping:" followed by whichever line hits the 2975 bytes. If I shorten the mapping, the error goes away. Thanks for the sure fast follow up! > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson >Assignee: Rob Petti > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159189#comment-159189 ] Bruno P. Kinoshita commented on JENKINS-12810: -- Hi Vignesh! Glad to hear that you are using the plug-in and the execution status is working. Let's focus on the attachments now. Could you give more information on your project? Try to explain here what you are using in your project. Say, if it's a TestNG project with Selenium, how are you creating/destroying WebDriver. You're using tap4j, right? How are you using TestNG/JUnit with TAP? Or are you using something different, like Python, Ruby? The more information you can provide on your project, the merrier. I will try to set up a similar environment here. Cheers, B > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: last_tc.png, tc1.png, tc2.png > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159190#comment-159190 ] Rob Petti commented on JENKINS-12806: - I'm able to reproduce the problem, but clicking on the ERROR link doesn't seem to do anything for me. I suspect this is simply the form validation overflowing the maximum url length of either the server or the browser... I'll take a look to see if the form validation scripts will support HTTP POST requests instead of GET requests. That should solve the issue. In the meantime, I believe you can safely ignore this error. > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson >Assignee: Rob Petti > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12806) Perforce Plugin causes config page to throw error if workspace mapping exceeds 2974 bytes
[ https://issues.jenkins-ci.org/browse/JENKINS-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti updated JENKINS-12806: Priority: Minor (was: Major) > Perforce Plugin causes config page to throw error if workspace mapping > exceeds 2974 bytes > - > > Key: JENKINS-12806 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12806 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Windows 2003 R1 32 Bit / Jenkins 1.450 / Perforce 1.3.7 >Reporter: Mike Henderson >Assignee: Rob Petti >Priority: Minor > Labels: jenkins, user, windows > Attachments: config.xml > > > I have a job that gathers a lot of different components from Perforce and we > recently added a few new lines. After the job built once we attemt to go > back into the config screen for the job and the settings come up but we get a > "ERROR" just below the mapping that once you click on it it shows a 404 error > and after that the user is logged out of Jenkins. If I delete the project > mapping from the config.xml and reload from the disk the job is editable > again until the next build. I have tried to use the clientspec feature but > this also adds back in the key in the config.xml and again the > error reoccurs after the first build. Right now the only work around is to > modify the job file manually with a text editor. The jobs seem to build just > fine. I have attached a job config file to show the issue. If I reduce the > mapping down to 2974 bytes the error goes away and does not seem to return. > My feeling is it is in the parser of the mapping, but that is a guess. For > user login control we currently are using "Project-based Matrix Authorization > Strategy" with "Jenkins's own user database". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11894) All tests {test Methods} of TestNG, belonging to the same class are shown as "FAILURE", if just one of the test is a failure
[
https://issues.jenkins-ci.org/browse/JENKINS-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159191#comment-159191
]
SCM/JIRA link daemon commented on JENKINS-11894:
Code changed in jenkins
User: Bruno P. Kinoshita
Path:
src/main/java/hudson/plugins/testlink/result/TAPFileNameResultSeeker.java
src/main/java/hudson/plugins/testlink/result/TestNGClassNameResultSeeker.java
src/main/java/hudson/plugins/testlink/result/TestNGMethodNameResultSeeker.java
src/main/java/hudson/plugins/testlink/result/TestNGSuiteNameResultSeeker.java
src/test/java/hudson/plugins/testlink/TestTestLinkBuilder.java
src/test/java/hudson/plugins/testlink/result/TestJUnitCaseNameResultSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTAPFileNameResultSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTestNGClassNameResultSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTestNGClassSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTestNGMethodNameResultSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTestNGSuiteNameResultSeeker.java
src/test/java/hudson/plugins/testlink/result/TestTestNGSuiteSeeker.java
src/test/java/hudson/plugins/testlink/result/issue10849/TestPerformance10849.java
src/test/java/hudson/plugins/testlink/result/issue9054/TestPlatformSupport.java
src/test/java/hudson/plugins/testlink/result/issue9229/TestIssue9229.java
src/test/java/hudson/plugins/testlink/result/issue9672/TestIssue9672.java
src/test/java/hudson/plugins/testlink/result/issue9672/TestTestResultSeekerTAP.java
src/test/java/hudson/plugins/testlink/util/TestReportSummary.java
http://jenkins-ci.org/commit/testlink-plugin/dfed1274f47ced08bc7d6592f59277611407c715
Log:
JENKINS-11894 Fixed all the tests
> All tests {test Methods} of TestNG, belonging to the same class are shown as
> "FAILURE", if just one of the test is a failure
> -
>
> Key: JENKINS-11894
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11894
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
> Environment: Jenkins Version 1.440 {Testlink Plugin - Version 3.0.2}
> Testlink Version 1.9.3 (Prague)
>Reporter: Venugopal Shenoy
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Labels: plugin
> Attachments: testng-results.xml
>
>
> Create one TestNG test class with several test methods {say 3 methods}. One
> of the test is deliberately failed {using assertTrue(false);}. All the
> tests are shown as failure in Testlink, when the testng xml test results are
> pushed to testlink using the Jenkins-Testlink plugin. {TestNG XML Results
> file is attached}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159192#comment-159192 ] Vignesh Senapathy commented on JENKINS-12810: - Hi Bruno, I am using JUnit project with Selenium. JUnit reports are generated once the scripts are run. I am not using TAP. I am just trying to attach the results in the JUnit results into each of the test case in Testlink. Below is the scenario: Have JUnit automated test scripts Have a job in Jenkins to run those scripts using ANT Once the job finishes testlink XMP-RPC scans through the test results which has more than one Test class name in it. But the attachments which gets passed to Testlink is wrongly attached meaning 1st testcase in the test execution has 6 test results, then the next one has 5 and so on. Have one key custom field which matches to the test class name in the test results XML. In the image last_tc.png you can see I have 6 test cases in it. I hope this helps. > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: last_tc.png, tc1.png, tc2.png > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11894) All tests {test Methods} of TestNG, belonging to the same class are shown as "FAILURE", if just one of the test is a failure
[
https://issues.jenkins-ci.org/browse/JENKINS-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-11894 stopped by Bruno P. Kinoshita.
> All tests {test Methods} of TestNG, belonging to the same class are shown as
> "FAILURE", if just one of the test is a failure
> -
>
> Key: JENKINS-11894
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11894
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
> Environment: Jenkins Version 1.440 {Testlink Plugin - Version 3.0.2}
> Testlink Version 1.9.3 (Prague)
>Reporter: Venugopal Shenoy
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Labels: plugin
> Attachments: testng-results.xml
>
>
> Create one TestNG test class with several test methods {say 3 methods}. One
> of the test is deliberately failed {using assertTrue(false);}. All the
> tests are shown as failure in Testlink, when the testng xml test results are
> pushed to testlink using the Jenkins-Testlink plugin. {TestNG XML Results
> file is attached}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11894) All tests {test Methods} of TestNG, belonging to the same class are shown as "FAILURE", if just one of the test is a failure
[
https://issues.jenkins-ci.org/browse/JENKINS-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159193#comment-159193
]
Bruno P. Kinoshita commented on JENKINS-11894:
--
Hey Venu.
The fix is done in the code, however I'm still tying everything together due to
some refactoring done in other parts. I need to finish updating Jelly scripts
and make sure nothing is broke. Won't take too long :)
Here's the result seeker for methods:
https://github.com/jenkinsci/testlink-plugin/blob/issue-11894/src/main/java/hudson/plugins/testlink/result/TestNGMethodNameResultSeeker.java
And the test:
https://github.com/jenkinsci/testlink-plugin/blob/issue-11894/src/test/java/hudson/plugins/testlink/result/TestTestNGMethodNameResultSeeker.java
We have Carnival in Brazil in few days, so I will have more time to work on
this. I'll cut a release before March.
All the best,
Bruno
> All tests {test Methods} of TestNG, belonging to the same class are shown as
> "FAILURE", if just one of the test is a failure
> -
>
> Key: JENKINS-11894
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11894
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
> Environment: Jenkins Version 1.440 {Testlink Plugin - Version 3.0.2}
> Testlink Version 1.9.3 (Prague)
>Reporter: Venugopal Shenoy
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Labels: plugin
> Attachments: testng-results.xml
>
>
> Create one TestNG test class with several test methods {say 3 methods}. One
> of the test is deliberately failed {using assertTrue(false);}. All the
> tests are shown as failure in Testlink, when the testng xml test results are
> pushed to testlink using the Jenkins-Testlink plugin. {TestNG XML Results
> file is attached}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159194#comment-159194 ] Bruno P. Kinoshita commented on JENKINS-12810: -- Hello Vignesh, thanks for the quick response. I'm not sure if I got it right. You are using the plug-in only to execute your JUnit+Selenium tests in Jenkins and have the execution status updated in TestLink. Then you are using a custom script to scan your workspace and upload attachments to TestLink. Is that right? Your set up for the plug-in seems correct. The only part that I didn't quite get it was how you upload the attachments. The plug-in does that, but only when you are using TAP. Thanks for providing further information :) B > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: last_tc.png, tc1.png, tc2.png > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9084) Regression in jenkins .401 maven plugin - deploy to repository post-task
[ https://issues.jenkins-ci.org/browse/JENKINS-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159195#comment-159195 ] manvendra tomar commented on JENKINS-9084: -- Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file (default-cli) on project standalone-pom: Failed to deploy artifacts: Could not transfer artifact abc.zip. Return code is: 401 I am getting this issue on Jenkins 1.450. while deploying artifact using a bat file. which is running from a pom.xml target using Jenkins. This works fine when I launch bat file, while fails when it launch through Jenkins. Please have a look on the issue. > Regression in jenkins .401 maven plugin - deploy to repository post-task > > > Key: JENKINS-9084 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9084 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: jenkins .401 >Reporter: David Karlsen >Assignee: olamy > > After upgrading to latest jenkins .401 the post-build task deploy to maven > repository has resurfaced: > Failed to transfer file: > http:///nexus/content/repositories/snapshots/some/artifact-1.2-20110317.153602-23.pom. > Return code is: 401 > This worked before upgrading. > I put in the url to deploy to + the server id in settings.xml containing the > credentials -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12427) BuildResultTrigger Plug-in not triggering job
[ https://issues.jenkins-ci.org/browse/JENKINS-12427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois reassigned JENKINS-12427: --- Assignee: gbois > BuildResultTrigger Plug-in not triggering job > -- > > Key: JENKINS-12427 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12427 > Project: Jenkins > Issue Type: Bug > Components: buildresult-trigger, buildresulttrigger >Affects Versions: current > Environment: Linux, 2.6.26-amd64 > debian_version 5.0.6 > Jenkins BuildResultTrigger Plug-in 0.4 > Jenkins ver. 1.440 >Reporter: S P >Assignee: gbois > Attachments: TEST-Trigger.config.xml, TEST-TRY.config.xml > > > Jenkins with the buildResultTrigger plugin is unable to trigger a job > Two jobs are setup, > 1. TEST-TRIGGER is a basic job that always passes > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:47:31 | 17/01/2012 10:47:31 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:47:31 | INFO: TEST-Trigger #7 main build > action completed: SUCCESS > > 2. TEST-TRY is a basic job configured to Monitor build results of > TEST-Trigger. This job is able to run with success when trigger manually > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:48:51 | 17/01/2012 10:48:51 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:48:51 | INFO: TEST-TRY #2 main build action > completed: SUCCESS > However, a success result from TEST-TRIGGER does not fire the TEST-TRY job. > Both jobs configurations are attached -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12427) BuildResultTrigger Plug-in not triggering job
[ https://issues.jenkins-ci.org/browse/JENKINS-12427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-12427. - Resolution: Not A Defect According the config files, there are no build results to check. Therefore, you have to click on the button 'Add a build result' in the build-result section. Do not hesitate to reopen the issue if it doesn't fix the issue. > BuildResultTrigger Plug-in not triggering job > -- > > Key: JENKINS-12427 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12427 > Project: Jenkins > Issue Type: Bug > Components: buildresult-trigger, buildresulttrigger >Affects Versions: current > Environment: Linux, 2.6.26-amd64 > debian_version 5.0.6 > Jenkins BuildResultTrigger Plug-in 0.4 > Jenkins ver. 1.440 >Reporter: S P >Assignee: gbois > Attachments: TEST-Trigger.config.xml, TEST-TRY.config.xml > > > Jenkins with the buildResultTrigger plugin is unable to trigger a job > Two jobs are setup, > 1. TEST-TRIGGER is a basic job that always passes > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:47:31 | 17/01/2012 10:47:31 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:47:31 | INFO: TEST-Trigger #7 main build > action completed: SUCCESS > > 2. TEST-TRY is a basic job configured to Monitor build results of > TEST-Trigger. This job is able to run with success when trigger manually > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:48:51 | 17/01/2012 10:48:51 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:48:51 | INFO: TEST-TRY #2 main build action > completed: SUCCESS > However, a success result from TEST-TRIGGER does not fire the TEST-TRY job. > Both jobs configurations are attached -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
