[JIRA] (JENKINS-13868) Could not create logger, quitting
Christian Wolfgang created JENKINS-13868: Summary: Could not create logger, quitting Key: JENKINS-13868 URL: https://issues.jenkins-ci.org/browse/JENKINS-13868 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Reporter: Christian Wolfgang Assignee: Christian Wolfgang Priority: Critical Due to an error in the internal logger, starting Jenkins from a location where the user does not have access, will result in Could not create logger. Quitting! This renders Jenkins unstable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13869) [Unexpected termination of the channel] for Unix SSH slaves
Vassilena Treneva created JENKINS-13869: --- Summary: [Unexpected termination of the channel] for Unix SSH slaves Key: JENKINS-13869 URL: https://issues.jenkins-ci.org/browse/JENKINS-13869 Project: Jenkins Issue Type: Bug Components: jenkins-cloudformation Affects Versions: current Environment: Jenkins Master version: 1.464 hosted on Linux bambpmsauto 2.6.34.7-0.4-desktop #1 SMP PREEMPT 2010-10-07 19:07:51 +0200 x86_64 x86_64 x86_64 GNU/Linux Reporter: Vassilena Treneva Once we upgraded to 1.464 jobs that run on Unix virtual machines (using SSH launch method) started to fail with the error below. The use case is the following: We have a job that reverts the VM and triggers a parametrized build on install jobs passing the node label with NodeLabel parameter plugin. Nodes have In demand delay = 5 and Idle delay = 15. Node os: Linux vmbam09 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux ### Console Output for the failing jobs: Started by upstream project eda-vm-revert build number 4800 Building remotely on vmbam09.eur.ad.sag in workspace /home/vmtest/jenkins/workspace/eda-install FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:646) at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:821) at hudson.FilePath.mkdirs(FilePath.java:887) at hudson.model.AbstractProject.checkout(AbstractProject.java:1216) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:702) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13869) [Unexpected termination of the channel] for Unix SSH slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-13869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vassilena Treneva updated JENKINS-13869: Description: Once we upgraded to 1.464 jobs that run on Unix virtual machines (using SSH launch method) started to fail with the error below. The use case is the following: We have a job that reverts the VM and triggers a parametrized build on install jobs passing the node label with NodeLabel parameter plugin. Nodes have In demand delay = 5 and Idle delay = 15. Node os: Linux vmbam09 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux Console Output for the failing jobs: Started by upstream project eda-vm-revert build number 4800 Building remotely on vmbam09.eur.ad.sag in workspace /home/vmtest/jenkins/workspace/eda-install FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:646) at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:821) at hudson.FilePath.mkdirs(FilePath.java:887) at hudson.model.AbstractProject.checkout(AbstractProject.java:1216) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:702) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) was: Once we upgraded to 1.464 jobs that run on Unix virtual machines (using SSH launch method) started to fail with the error below. The use case is the following: We have a job that reverts the VM and triggers a parametrized build on install jobs passing the node label with NodeLabel parameter plugin. Nodes have In demand delay = 5 and Idle delay = 15. Node os: Linux vmbam09 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux ### Console Output for the failing jobs: Started by upstream project eda-vm-revert build number 4800 Building remotely on vmbam09.eur.ad.sag in workspace /home/vmtest/jenkins/workspace/eda-install FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:646) at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:821) at hudson.FilePath.mkdirs(FilePath.java:887) at hudson.model.AbstractProject.checkout(AbstractProject.java:1216) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:702) at
[JIRA] (JENKINS-13735) Jenkins starts wrong slave for job restricted to specific one
[ https://issues.jenkins-ci.org/browse/JENKINS-13735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163103#comment-163103 ] Marco Lehnort commented on JENKINS-13735: - I forked, applied the change and added a pull request: https://github.com/jenkinsci/jenkins/pull/481. Jenkins starts wrong slave for job restricted to specific one - Key: JENKINS-13735 URL: https://issues.jenkins-ci.org/browse/JENKINS-13735 Project: Jenkins Issue Type: Bug Components: master-slave, slave-setup, vsphere-cloud Affects Versions: current Environment: Jenkins 1.463 under Tomcat6 on Linux (SLES 11), Windows XP slave VMs controlled via vSphere Cloud plugin Reporter: Marco Lehnort Assignee: Kohsuke Kawaguchi Labels: slave I'm using the following setup: - WinXP slaves A,B,C - jobs jA, jB, jC, tied to slaves A,B,C respectively using Restrict where this job can run Assume all slaves are disconnected and powered off, no builds are queued. When starting a build manually, say jC, the following will happen: - job jC will be scheduled and also displayed accordingly in the build queue - tooltip will say it's waiting because slave C is offline - next, slave A is powered on by Jenkins and connection is established - jC will not be started, Jenkins seems to honor the restriction correctly - after some idle time, Jenkins realizes the slave is idle and causes shut down - then, same procedure happens with slave B - on occasion, next one is slave A again - finally (on good luck?) slave C happens to be started - jC is executed It is possible that jC is waiting for hours (indefinitely?), because the required slave is not powered on. I also observed this behaviour using a time-trigger instead of manual trigger, so I assume it is independent of the type of trigger. Occasionally it also happens that the correct slave is powered up right away, but that seems to happen by chance. The concrete pattern is not obvious to me. Note that the component selection above is just my best guess. Cheers, Marco -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13472) java.lang.IllegalArgumentException: Can't parse job-name
[
https://issues.jenkins-ci.org/browse/JENKINS-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163104#comment-163104
]
Victor Martinez commented on JENKINS-13472:
---
Exactly the same for us with Jenkins 1.464, using Manual approval.
java.lang.IllegalArgumentException: Can't parse job-name
---
Key: JENKINS-13472
URL: https://issues.jenkins-ci.org/browse/JENKINS-13472
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: Jenkins 1.458
Reporter: Brian Murrell
Priority: Blocker
Using version 2.5 of the Jenkins promoted builds plugin I get the following
when I try to promote a build that has no previous promotions:
{code}
java.lang.IllegalArgumentException: Can't parse job-name
at hudson.matrix.Combination.fromString(Combination.java:218)
at hudson.matrix.MatrixProject.getItem(MatrixProject.java:568)
at hudson.matrix.MatrixProject.getItem(MatrixProject.java:90)
at jenkins.model.Jenkins.getItem(Jenkins.java:2158)
at jenkins.model.Jenkins.getItem(Jenkins.java:2179)
at
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
at
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
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:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:485)
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.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at
hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
at
[JIRA] (JENKINS-9899) Permissions check of custom workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163105#comment-163105 ] vjuranek commented on JENKINS-9899: --- Not completely sure why I created this issue, probably just not to forget Kutzi's comment under pull #147 [1]. Anyway, I have similar opinion as you [2], so I'm perfecly fine with Won't fix :-) [1] https://github.com/jenkinsci/jenkins/pull/147 [2] https://github.com/jenkinsci/jenkins/pull/147#issuecomment-1307578 Permissions check of custom workspace - Key: JENKINS-9899 URL: https://issues.jenkins-ci.org/browse/JENKINS-9899 Project: Jenkins Issue Type: New Feature Components: core Reporter: vjuranek Implement a check if custom workspace can point into specified directory - e.g. check if it points to another workspace which is inaccessible for the user due to Project-based Matrix Authorization Strategy setup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13472) java.lang.IllegalArgumentException: Can't parse job-name
[
https://issues.jenkins-ci.org/browse/JENKINS-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161807#comment-161807
]
Sylvain Veyrié edited comment on JENKINS-13472 at 5/23/12 9:06 AM:
---
Exactly the same for us with Jenkins 1.459, using Manual approval.
Workaround: promote using Force promotion.
Going back to 2.4 solves the problem.
was (Author: turb):
Exactly the same for us with Jenkins 1.459, using Manual approval.
Turnaround: promote using Force promotion.
Going back to 2.4 solves the problem.
java.lang.IllegalArgumentException: Can't parse job-name
---
Key: JENKINS-13472
URL: https://issues.jenkins-ci.org/browse/JENKINS-13472
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: Jenkins 1.458
Reporter: Brian Murrell
Priority: Blocker
Using version 2.5 of the Jenkins promoted builds plugin I get the following
when I try to promote a build that has no previous promotions:
{code}
java.lang.IllegalArgumentException: Can't parse job-name
at hudson.matrix.Combination.fromString(Combination.java:218)
at hudson.matrix.MatrixProject.getItem(MatrixProject.java:568)
at hudson.matrix.MatrixProject.getItem(MatrixProject.java:90)
at jenkins.model.Jenkins.getItem(Jenkins.java:2158)
at jenkins.model.Jenkins.getItem(Jenkins.java:2179)
at
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
at
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
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:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
at
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:571)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:656)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:485)
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.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
[JIRA] (JENKINS-13871) Using Conditional build step and Parameterized build step in same step is preventing parallel executions of same job
Jacobo Jimenez created JENKINS-13871: Summary: Using Conditional build step and Parameterized build step in same step is preventing parallel executions of same job Key: JENKINS-13871 URL: https://issues.jenkins-ci.org/browse/JENKINS-13871 Project: Jenkins Issue Type: Bug Components: conditional-buildstep, parameterized-trigger, run-condition Affects Versions: current Environment: GNU/Linux x86_64 2.6.16.60-0.69.1-smp Tomcat Reporter: Jacobo Jimenez Assignee: domi Job A triggers a variable number of job B depending on a environment variable. It can be zero but since Counter Parameter Factory doesnt allow zero repetitions (Java exception) I had to include this step as a conditional build step. Job A must wait until the end of all B jobs so option Block until the triggered projects finish their builds is selected (because it is really a diamond execution). This jobs configuration works fine but if you launch another A (in parallel) when it finish its first step and reach conditional step, it get stuck waiting until the end of all the jobs from first execution, once first A execution finished second execution continue executing its B jobs. This is a kind of interlocking process between executions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13872) Counter Parameter Factory
Jacobo Jimenez created JENKINS-13872: Summary: Counter Parameter Factory Key: JENKINS-13872 URL: https://issues.jenkins-ci.org/browse/JENKINS-13872 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Affects Versions: current Environment: GNU/Linux x86_64 2.6.16 Tomcat Reporter: Jacobo Jimenez Assignee: huybrechts Defining a Trigger/call builds on other projects build step with Counter Parameter Factory as follow: FROM = 1 TO = $VARIABLE STEP = 1 It should do nothing, I mean, do not build step, if $VARIABLE is zero but it is failing with following exception: FATAL: Counting with step size 0 will not terminate! java.lang.RuntimeException: Counting with step size 0 will not terminate! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13547) Jenkins runs extremely slow with remote crowd server
[ https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163106#comment-163106 ] Thomas Lehmann commented on JENKINS-13547: -- I can confirm this bug in an intranet application. Since I've activated security with crowd authentication through the crowd2 plugin Jenkis is extremely slow. It takes upto 10 seconds to load the overview or a configuation page. Even opening the conextmenus takes 3-4 seconds when hovering context sensitive links. IMO this is unusable. Really! I'll try to debug this these days to tisolate the problem, but I'm sure this is related to the crowd2 plugin. Jenkins runs extremely slow with remote crowd server Key: JENKINS-13547 URL: https://issues.jenkins-ci.org/browse/JENKINS-13547 Project: Jenkins Issue Type: Bug Components: crowd2 Environment: Centos/RHEL 6.2 Jenkins 1.460 Crowd 2.2.7 Reporter: Joel Pearson Assignee: Thorsten Heit Priority: Critical When Crowd is running on a different continent to Jenkins, the performance of Jenkins is drastically affected, to the point that Jenkins is unusable. It seems like that every request to Jenkins gets authenticated to Crowd or something like that. The original Crowd plugin does not have this problem and does not affect the performance of Jenkins in any visible form. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13547) Jenkins runs extremely slow with remote crowd server
[ https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163107#comment-163107 ] Thomas Lehmann commented on JENKINS-13547: -- Our configuration: CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64 Jenkins 1.462 Crowd 2 integration 1.4 Against Crowd 2.4.2 All other atlassian applications run quiete fast. Jenkins runs extremely slow with remote crowd server Key: JENKINS-13547 URL: https://issues.jenkins-ci.org/browse/JENKINS-13547 Project: Jenkins Issue Type: Bug Components: crowd2 Environment: Centos/RHEL 6.2 Jenkins 1.460 Crowd 2.2.7 Reporter: Joel Pearson Assignee: Thorsten Heit Priority: Critical When Crowd is running on a different continent to Jenkins, the performance of Jenkins is drastically affected, to the point that Jenkins is unusable. It seems like that every request to Jenkins gets authenticated to Crowd or something like that. The original Crowd plugin does not have this problem and does not affect the performance of Jenkins in any visible form. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13547) Jenkins runs extremely slow with remote crowd server
[
https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163107#comment-163107
]
Thomas Lehmann edited comment on JENKINS-13547 at 5/23/12 11:56 AM:
Our configuration:
{quote}
CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64
Jenkins 1.462
Crowd 2 integration 1.4
{quote}
{quote}
Against Crowd 2.4.2
{quote}
All other atlassian applications run quiete fast.
was (Author: tholewebgods):
Our configuration:
CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64
Jenkins 1.462
Crowd 2 integration 1.4
Against Crowd 2.4.2
All other atlassian applications run quiete fast.
Jenkins runs extremely slow with remote crowd server
Key: JENKINS-13547
URL: https://issues.jenkins-ci.org/browse/JENKINS-13547
Project: Jenkins
Issue Type: Bug
Components: crowd2
Environment: Centos/RHEL 6.2
Jenkins 1.460
Crowd 2.2.7
Reporter: Joel Pearson
Assignee: Thorsten Heit
Priority: Critical
When Crowd is running on a different continent to Jenkins, the performance of
Jenkins is drastically affected, to the point that Jenkins is unusable.
It seems like that every request to Jenkins gets authenticated to Crowd or
something like that.
The original Crowd plugin does not have this problem and does not affect the
performance of Jenkins in any visible form.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13873) Build should not trigger when there is no changes in perforce
ekambaram varathan created JENKINS-13873: Summary: Build should not trigger when there is no changes in perforce Key: JENKINS-13873 URL: https://issues.jenkins-ci.org/browse/JENKINS-13873 Project: Jenkins Issue Type: Bug Components: jenkins-plugin-runtime Affects Versions: current Environment: ubuntu Reporter: ekambaram varathan Assignee: Jørgen Tjernø Priority: Critical Fix For: current Regular basis we have scheduled builds which generally runs the build twice in a day. Assume that first build runs at 4pm and second build runs at 10pm. Here the problem is when there is no code changes in perforce though the builds runs at 10pm(Here my 4pm build already has the latest codes). So please help me how to resolve when there is no code changes in perforce it's should not run the build at 10pm. Thanks in advance. Thanks, Ekambaram. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13867) Configuration slicing for Maven versions should apply to Free style projects
[ https://issues.jenkins-ci.org/browse/JENKINS-13867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Robertson resolved JENKINS-13867. --- Resolution: Fixed look for change in version 1.31 Configuration slicing for Maven versions should apply to Free style projects Key: JENKINS-13867 URL: https://issues.jenkins-ci.org/browse/JENKINS-13867 Project: Jenkins Issue Type: New Feature Components: configurationslicing Reporter: Jacob Robertson Assignee: Jacob Robertson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13874) java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z
Xavier Nodet created JENKINS-13874: -- Summary: java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z Key: JENKINS-13874 URL: https://issues.jenkins-ci.org/browse/JENKINS-13874 Project: Jenkins Issue Type: Bug Components: thinBackup Affects Versions: current Environment: Jenkins 1.456, thinBackup 1.6 Reporter: Xavier Nodet Assignee: Thomas Fürer I installed thinBackup 1.6 on our Jenkins 1.456. I didn't restart the server yet. In thinBackup's settings page, I get an 'ERROR' below each of 'Backup directory', 'Backup schedule for full backups', 'Backup schedule for differential backups' and 'Files excluded from backup'. The Stacktrace is as follows: java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z at org.jvnet.hudson.plugins.thinbackup.ThinBackupPluginImpl.doCheckBackupPath(ThinBackupPluginImpl.java:234) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.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.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:245) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:148) at java.lang.Thread.run(Thread.java:811) Generated by Winstone Servlet Engine v0.9.10 at Wed May 23 06:13:08 PDT 2012 Is there something wrong with my configuration? 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-13866) Configuration slicing for parameters
[ https://issues.jenkins-ci.org/browse/JENKINS-13866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Robertson resolved JENKINS-13866. --- Resolution: Fixed look for change in version 1.31 Configuration slicing for parameters Key: JENKINS-13866 URL: https://issues.jenkins-ci.org/browse/JENKINS-13866 Project: Jenkins Issue Type: New Feature Components: configurationslicing Reporter: Jacob Robertson Assignee: Jacob Robertson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13850) Unable to match emails for Regular Expression Job Filter on Match Value Email recipients
[ https://issues.jenkins-ci.org/browse/JENKINS-13850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Robertson resolved JENKINS-13850. --- Resolution: Fixed look for this fix in the upcoming 1.21 version Unable to match emails for Regular Expression Job Filter on Match Value Email recipients Key: JENKINS-13850 URL: https://issues.jenkins-ci.org/browse/JENKINS-13850 Project: Jenkins Issue Type: Bug Components: view-job-filters Affects Versions: current Environment: Jenkins 1.464 View Job Filters 1.20 Other installed plugins: javadoc 1.0 Maven Integration plugin1.464 ant 1.1 Dashboard View 2.2 Jenkins Release Plugin 2.2 CVS Plugin 1.6 Subversion Plugin 1.34 Translation Assistance Plugin 1.8 Jenkins SSH Slaves plugin 0.21 Log Parser Plugin 1.0.8 Static Code Analysis Plug-ins 1.40 PMD Plugin 3.27 Checkstyle Plugin 3.26 FindBugs Plugin 4.39 Jenkins batch task plugin 1.16 Jenkins disk-usage plugin 0.16 JIRA Plugin 1.31 Task Scanner Plugin 4.29 Analysis Collector Plugin 1.26 Reporter: Michael Duez Assignee: Jacob Robertson Labels: plugin 1) Assigned regular expression .* to standard view filter Use a regular expression to include jobs into the view, which caused all jobs to be listed in the view. 2) Added Regular Expression Job Filter of Match Value Email recipients with a Regular Expression of .*com.* 3) Set Match Type to Exclude Unmatched - Filter out jobs that don't match this filter. Result: No jobs appear in the view. I expected all jobs to be listed (every job has one or more .*com.* values for email recipients). 4) Set Regular Expression to .*, and this also resulted in no jobs listed in the view. No errors have appeared in the Jenkins server.log. Looking at a sample job config.xml file, here's the location of the email addresses I'm expecting the filter to match (recipients.../recipients): reporters hudson.maven.reporters.MavenMailer recipients[address1@redacted].com [address2@redacted].com/recipients dontNotifyEveryUnstableBuildfalse/dontNotifyEveryUnstableBuild sendToIndividualsfalse/sendToIndividuals perModuleEmailtrue/perModuleEmail /hudson.maven.reporters.MavenMailer /reporters This plugin is only useful to our environment if we can match on email recipients (and it will be extremely valuable it it can!), thus the Major priority. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13875) Always triggers the same set of job, even when env changes
Nicolas De Loof created JENKINS-13875: - Summary: Always triggers the same set of job, even when env changes Key: JENKINS-13875 URL: https://issues.jenkins-ci.org/browse/JENKINS-13875 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Reporter: Nicolas De Loof Assignee: huybrechts when job list to be triggered as a build step is configured from environment, the plugin caches the expanded value and don't re-resolve it later, so that the same set of jobs is always triggered even if env changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163112#comment-163112 ] Balthasar Nebel commented on JENKINS-13241: --- Im getting the same exception as Soumen Banerjee with Jenkins 1.465. Jenkins runs on SLES 11 and Slave runs on AIX 7.1. So this issue is still alive and I propose to reopen this bug or open another. Artifact archiving from remote slave fails -- Key: JENKINS-13241 URL: https://issues.jenkins-ci.org/browse/JENKINS-13241 Project: Jenkins Issue Type: Bug Components: core Reporter: Vyacheslav Karpukhin Since 1.456 jenkins stopped archiving artifacts from remote slave. This affects both 1.456 and 1.457, works correctly with 1.455. ERROR: Failed to archive artifacts: build/Release/*.app/**/* hudson.util.IOException2: hudson.util.IOException2: Failed to extract /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/* at hudson.FilePath.readFromTar(FilePath.java:1817) at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.io.IOException: Failed to chmod /mnt/storage/.jenkins/jobs/NGB_Queues/builds/2012-03-27_03-11-27/archive/build/Release/NGB Queues.app/Contents/Frameworks/BWToolkitFramework.framework/BWToolkitFramework : No such file or directory at hudson.FilePath._chmod(FilePath.java:1248) at hudson.FilePath.readFromTar(FilePath.java:1813) ... 12 more at hudson.FilePath.copyRecursiveTo(FilePath.java:1736) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$2.adapt(Channel.java:714) at hudson.remoting.Channel$2.adapt(Channel.java:709) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.FilePath.copyRecursiveTo(FilePath.java:1732) ... 11 more Caused by: java.io.IOException: Pipe is already closed at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83) at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171) at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118) at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109) at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161) at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118) at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410) at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351) at hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356) at hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137) at hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149) at
[JIRA] (JENKINS-8663) Parsing of POM happens before SNAPSHOT-Parents are updated
[ https://issues.jenkins-ci.org/browse/JENKINS-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163113#comment-163113 ] SCM/JIRA link daemon commented on JENKINS-8663: --- Code changed in jenkins User: Vincent Latombe Path: changelog.html maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java maven-plugin/src/main/java/hudson/maven/MavenUtil.java http://jenkins-ci.org/commit/jenkins/feddca252bc2bb295e8b37a24a9063c31b37e702 Log: [FIXED JENKINS-8663] Flag -U is not used during the parsing step of a Maven Job If the -U flag is specified in the goals/options of the build step of a Maven job, it should be used as well in the parsing step. (cherry picked from commit 1421ca15d5a36706214476e613eeab789b9066df) Conflicts: changelog.html Parsing of POM happens before SNAPSHOT-Parents are updated -- Key: JENKINS-8663 URL: https://issues.jenkins-ci.org/browse/JENKINS-8663 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Hudson 1.394 Reporter: Stephan Pauxberger Priority: Blocker Given the following constellation. Project A 1.0-SNAPSHOT (POM only) Project B 1.0-SNAPSHOT (Jar, has A as parent) Both jobs use private Maven repositories. Both projects have a separate job. Change something in project A, commit. Job A builds and deploys to repository Change something in project B that dependes on changes in project A. Commit. Job B starts an resolves the POM using the old parent POM, potentially leading to a broken build. For example: B declares a dependency WITH a version. Now remove the version from B and enter a dependencyManagement entry into A. Commit A, later B. Result: B fails because pom validation has no valid version for the dependency. Only solution (since private repositories are used): Clean workspace of B via Webinterface, the rebuild B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163114#comment-163114 ] SCM/JIRA link daemon commented on JENKINS-12994: Code changed in jenkins User: Vincent Latombe Path: core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/210e50fc8547c99d66b033787371dae115f03b7e Log: [FIX JENKINS-12994] Quiet period is blocking other jobs in queue Queue#maintain() was returning too soon(cherry picked from commit 394e9d6c0488fae6834d97a158a018abb31f3179) Conflicts: core/src/main/java/hudson/model/Queue.java Quiet period is blocking other jobs in queue Key: JENKINS-12994 URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: teetoivo Priority: Critical Starting from version 1.452, a job in queue waiting for the quiet period to pass is blocking all other jobs that have been queued after it. Example: # Job A has quiet period set to 10 seconds # Job B has quiet period set to 300 seconds # Job C has quiet period set to 100 seconds # Jobs get queued in A-B-C order. # Job A starts executing after 10 seconds # After 100 seconds, status of job C changes to pending - Waiting for next available executor even if free executors are available # After 300 seconds both jobs B and C start executing This problem is hardly visible when short quiet periods are used but becomes problematic with longer quiet periods or plugins like Naginator that will increase the quiet period to hours if the builds fail enough. Version 1.451 is the last release where this problem isn't visible. From public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163115#comment-163115 ] SCM/JIRA link daemon commented on JENKINS-12994: Code changed in jenkins User: Vincent Latombe Path: changelog.html http://jenkins-ci.org/commit/jenkins/a86887043605c6070c81894bf38e4c6084e1f229 Log: Update changelog for JENKINS-12994(cherry picked from commit 07b3f2cccb077df85617f2748f9b329528bc263b) Conflicts: changelog.html Quiet period is blocking other jobs in queue Key: JENKINS-12994 URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: teetoivo Priority: Critical Starting from version 1.452, a job in queue waiting for the quiet period to pass is blocking all other jobs that have been queued after it. Example: # Job A has quiet period set to 10 seconds # Job B has quiet period set to 300 seconds # Job C has quiet period set to 100 seconds # Jobs get queued in A-B-C order. # Job A starts executing after 10 seconds # After 100 seconds, status of job C changes to pending - Waiting for next available executor even if free executors are available # After 300 seconds both jobs B and C start executing This problem is hardly visible when short quiet periods are used but becomes problematic with longer quiet periods or plugins like Naginator that will increase the quiet period to hours if the builds fail enough. Version 1.451 is the last release where this problem isn't visible. From public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13448) Guice injector failure can cause failure of whole Jenkins
[ https://issues.jenkins-ci.org/browse/JENKINS-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163116#comment-163116 ] SCM/JIRA link daemon commented on JENKINS-13448: Code changed in jenkins User: Vojtech Juranek Path: core/src/main/java/hudson/ExtensionFinder.java http://jenkins-ci.org/commit/jenkins/91d88d0508c09a8fbc42f8187347c90c8b79e47e Log: [FIXED JENKINS-13448] Added additional checks if Guice will be able to create injector to exclude missing extension poins. (cherry picked from commit 6788f82a2c9f8e3580440913c2d39f1d1dc3ad70) Guice injector failure can cause failure of whole Jenkins - Key: JENKINS-13448 URL: https://issues.jenkins-ci.org/browse/JENKINS-13448 Project: Jenkins Issue Type: Bug Components: core Reporter: vjuranek Priority: Critical When Guice fails to create injector (e.g. because some extension point is optional and therefore missing), it can break other plugins and eventually crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1152) Mail server rejecting emails from hudson
[ https://issues.jenkins-ci.org/browse/JENKINS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163117#comment-163117 ] SCM/JIRA link daemon commented on JENKINS-1152: --- Code changed in jenkins User: Christoph Kutzinski Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/efce00a177bd4d6ac64cad481544729e90144358 Log: Update JavaMail dependency to 1.4.4. Should fix JENKINS-1152 and JENKINS-3983(cherry picked from commit 4afaf0bbc2c9f7298c45dc527269fb5c81cc710d) Mail server rejecting emails from hudson Key: JENKINS-1152 URL: https://issues.jenkins-ci.org/browse/JENKINS-1152 Project: Jenkins Issue Type: Bug Components: mail Affects Versions: current Environment: Platform: All, OS: All Reporter: typerlc Assignee: kutzi When sending emails from hudson, my mail server (postfix, but I'm sure others will behave similarly too) rejects the message because the smtp HELO message isn't being sent. This is because the system property mail.smtp.localhost hasn't been set before sending the email. This is described in the javadocs for com.sun.mail.smtp. See also: http://forum.java.sun.com/thread.jspa?threadID=482673messageID=2252508. The solution is to add some code in hudson.tasks.Mailer.createSession() like: props.put(mail.smtp.localhost, localServerName); I guess some code to pull the localServerName out of config would be needed to. In theory, a work around might be setting a system property when running hudson, but I've not been able to make this work yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3983) SMTP authentication not working
[ https://issues.jenkins-ci.org/browse/JENKINS-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163118#comment-163118 ] SCM/JIRA link daemon commented on JENKINS-3983: --- Code changed in jenkins User: Christoph Kutzinski Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/efce00a177bd4d6ac64cad481544729e90144358 Log: Update JavaMail dependency to 1.4.4. Should fix JENKINS-1152 and JENKINS-3983(cherry picked from commit 4afaf0bbc2c9f7298c45dc527269fb5c81cc710d) SMTP authentication not working --- Key: JENKINS-3983 URL: https://issues.jenkins-ci.org/browse/JENKINS-3983 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: PC, OS: All Reporter: marcb Attachments: stacktrace.txt I've tried to use my Exchange 2007 server as an SMTP server for Hudson, which requires SMTP authentication. I configured the standard authentication settings which have been confirmed to work on Outlook, Outlook Express as well as our office printer (which can sending scans by email). When sending a test email, or having emails sent after a build, I get the following: com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.1 Client was not authenticated See attachment for full stack trace. It would appear the problem is related to the way JavaMail is called in Hudson. The following FAQ entry describes the problem: http://java.sun.com/products/javamail/FAQ.html#smtpauth I checked hudson.tasks.Mailer in core/src/main/java/hudson/tasks and it seems indeed that JavaMail is being called using Transport.send(msg) instead of the method suggested in the FAQ above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1152) Mail server rejecting emails from hudson
[ https://issues.jenkins-ci.org/browse/JENKINS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163119#comment-163119 ] SCM/JIRA link daemon commented on JENKINS-1152: --- Code changed in jenkins User: Christoph Kutzinski Path: changelog.html http://jenkins-ci.org/commit/jenkins/f481b1971d32141219e33aad5f449b45463a8e7c Log: Changelog for JENKINS-1152 and JENKINS-3983 (cherry picked from commit c4dd892ea3067be942d4a89778029ed1522512ff) Conflicts: changelog.html Mail server rejecting emails from hudson Key: JENKINS-1152 URL: https://issues.jenkins-ci.org/browse/JENKINS-1152 Project: Jenkins Issue Type: Bug Components: mail Affects Versions: current Environment: Platform: All, OS: All Reporter: typerlc Assignee: kutzi When sending emails from hudson, my mail server (postfix, but I'm sure others will behave similarly too) rejects the message because the smtp HELO message isn't being sent. This is because the system property mail.smtp.localhost hasn't been set before sending the email. This is described in the javadocs for com.sun.mail.smtp. See also: http://forum.java.sun.com/thread.jspa?threadID=482673messageID=2252508. The solution is to add some code in hudson.tasks.Mailer.createSession() like: props.put(mail.smtp.localhost, localServerName); I guess some code to pull the localServerName out of config would be needed to. In theory, a work around might be setting a system property when running hudson, but I've not been able to make this work yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3983) SMTP authentication not working
[ https://issues.jenkins-ci.org/browse/JENKINS-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163120#comment-163120 ] SCM/JIRA link daemon commented on JENKINS-3983: --- Code changed in jenkins User: Christoph Kutzinski Path: changelog.html http://jenkins-ci.org/commit/jenkins/f481b1971d32141219e33aad5f449b45463a8e7c Log: Changelog for JENKINS-1152 and JENKINS-3983 (cherry picked from commit c4dd892ea3067be942d4a89778029ed1522512ff) Conflicts: changelog.html SMTP authentication not working --- Key: JENKINS-3983 URL: https://issues.jenkins-ci.org/browse/JENKINS-3983 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: PC, OS: All Reporter: marcb Attachments: stacktrace.txt I've tried to use my Exchange 2007 server as an SMTP server for Hudson, which requires SMTP authentication. I configured the standard authentication settings which have been confirmed to work on Outlook, Outlook Express as well as our office printer (which can sending scans by email). When sending a test email, or having emails sent after a build, I get the following: com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.1 Client was not authenticated See attachment for full stack trace. It would appear the problem is related to the way JavaMail is called in Hudson. The following FAQ entry describes the problem: http://java.sun.com/products/javamail/FAQ.html#smtpauth I checked hudson.tasks.Mailer in core/src/main/java/hudson/tasks and it seems indeed that JavaMail is being called using Transport.send(msg) instead of the method suggested in the FAQ above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163123#comment-163123 ] SCM/JIRA link daemon commented on JENKINS-13238: Code changed in jenkins User: Seiji Sogabe Path: core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly http://jenkins-ci.org/commit/jenkins/007cd042b59a07f2b3243131b6494ef7a97d7b3e Log: [FIXED JENKINS-13238] Loading All Build History Fails (cherry picked from commit a45ecf45ee8571aae7a0273784971afeeefb6e3c) Loading All Build History Fails --- Key: JENKINS-13238 URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: linux, jenkins 1.456 Reporter: Spencer Oliver Assignee: sogabe seems after the update from 1.455 to 1.456 causes an issue where pressing 'More' to expand the job Build History now fails with a 404. Calling the build history directly also causes the 404, eg. http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ For info rolling back to 1.455 cures the problem. tested 1.457 and issue still present. jenkins own server also shows the issue: http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/all/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9882) Jenkins runs out of file descriptors (winstone problem)
[ https://issues.jenkins-ci.org/browse/JENKINS-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163121#comment-163121 ] SCM/JIRA link daemon commented on JENKINS-9882: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html war/pom.xml http://jenkins-ci.org/commit/jenkins/5a28f6a7f7b3debf3ea2ac459603af0d8086395e Log: [FIXED JENKINS-9882] integrated a newer version of Winstone with the fix. (cherry picked from commit 8eb264ceb1bfdea332009499a06b9faa89dc03e9) Conflicts: changelog.html Jenkins runs out of file descriptors (winstone problem) --- Key: JENKINS-9882 URL: https://issues.jenkins-ci.org/browse/JENKINS-9882 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Environment: Debian 5, sun-java-jdk (1.6.0_22) Jenkins version: 1.414-SNAPSHOT Reporter: Santeri Paavolainen Running Jenkins with the embedded Winstone server for a long time under constant load conditions causes file descriptor and thread leakage. Environment: Debian 5, sun-java-jdk (1.6.0_22) Jenkins version: 1.414-SNAPSHOT What happens: After running for about 1 day the following appears on jenkins log file: [Winstone 2011/05/27 07:35:03] - WARNING: Request handler pool limit exceeded - waiting for retry and a bit later (this starts repeating): [Winstone 2011/05/27 07:43:25] - WARNING: Request handler pool limit exceeded - waiting for retry [Winstone 2011/05/27 07:43:26] - ERROR: Request ignored because there were no more request handlers available in the pool [Winstone 2011/05/27 07:43:36] - WARNING: Request handler pool limit exceeded - waiting for retry [Winstone 2011/05/27 07:43:37] - ERROR: Request ignored because there were no more request handlers available in the pool Jenkins then stops handling requests successfully - at the beginning intermittently, but finally basically failing almost all of the requests. Using VisualVM I can see that there is a thousand RequestHandlerThread threads in wait state, and that over 1200 file descriptors are currently in use. I think the requests start failing because winstone has a this limit: private int MAX_REQUEST_HANDLERS_IN_POOL = 1000; as it doesn't seem to be running out of available fds (apparently 8192 is the maximum in this setup). When I restart jenkins I can verify a slow buildup of threads and used file descriptors: * 10 minutes after restart: 136 live threads, 256 fds used * 20 minutes: 150 threads, 271 fds * 30 minutes: 161 threads, 280 fds * 110 minutes: 255 threads, 376 fds I've looked at the repository version of winstone, and looking at the code there seems to be a race condition in handling of the request handler pool. When a request is received by ObjectPool.handleRequest, it looks for an available request handler from unusedRequestHandlerThreads and calls commenceRequestHandling on the available thread. commenceRequestHandling in turn does this.notifyAll() to wake up the thread. So far so good. However when the thread has finished processing the request, it calls this.objectPool.releaseRequestHandler(this) and *then* waits. I think here's a race condition, since what can happen is that object pool called (CALL) and request handler thread (RH) can interleave like this: # RH (in RequestHandler.run): this.objectPool.releaseRequestHandler(this) # RH (in ObjectPool.releaseRequestHandler): this.unusedRequestHandlerThreads.add(rh) # CALL (in ObjectPool.handleRequest): take RH from unusedRequestHandlerThreads # CALL (in ObjectPool.handleRequest): rh.commenceRequestHandling(socket, listener); # CALL (in RequestHandler.commenceRequestHandling): this.notifyAll() # RH (in ObjectPool.run): this.wait() Since notify is lost (no waiters), this.wait() in the last step will hang forever. This will leak a file descriptor since the socket given to be processed is never reclaimed, and threads are effectively lost as Winstone will then create more RequestHandlers. Now, this is of course a winstone problem, but its development seems to be d-e-a-d at least looking at its bug tracker. As long as this problem affect Jenkins, I'd still classify it as a Jenkins problem too. I've put this into the winstone tracker too: https://sourceforge.net/tracker/?func=detailaid=3308285group_id=98922atid=622497 Workaround: Use Tomcat, not embedded winstone (that's what I'm doing now). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13649) Invalid environment variable values when running hierarchical jobs on windows slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163124#comment-163124 ] SCM/JIRA link daemon commented on JENKINS-13649: Code changed in jenkins User: Stephen Connolly Path: core/src/main/java/hudson/FilePath.java http://jenkins-ci.org/commit/jenkins/a957ccc8363ffb78f40abbf0f5afdc33d6877e24 Log: [FIXES JENKINS-13649] As FilePath(FilePath,String) expects multi-segment relative paths, we should ensure that the multiple segments are using the correct separator character for the remote OS (cherry picked from commit c92c2217ecb0078f021fab7c9a053d9e63f12143) Invalid environment variable values when running hierarchical jobs on windows slaves Key: JENKINS-13649 URL: https://issues.jenkins-ci.org/browse/JENKINS-13649 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: stephenconnolly Assignee: stephenconnolly If you try to run a hierarchical job on a windows slave the WORKSPACE environment variable will contain slashes. e.g. WORKSPACE=C:\JenkinsSlave\workspace\Folder/Test The root cause of this is that Slave.getWorkspaceFor(...) calls AbstractItem.getFullName() which will build up the name using '/' as the separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11353) Recognize test results from eviware:maven-soapui-plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163126#comment-163126 ] Roland Asmann commented on JENKINS-11353: - Has this been released yet? Recognize test results from eviware:maven-soapui-plugin --- Key: JENKINS-11353 URL: https://issues.jenkins-ci.org/browse/JENKINS-11353 Project: Jenkins Issue Type: Improvement Components: maven2, plugin Affects Versions: current Reporter: Nathan McDonald Priority: Minor Attachments: SurefireArchiver.java.diff, SurefireArchiver.java.diff maven-soap-ui plugin is capable of outputting surefire/junit style reports: http://www.soapui.org/Test-Automation/maven-2x.html If using freestyle project in jenkins, can specify to look in report output directory and jenkins will register the tests (test results on project show them). If using maven project, these tests do not show up. There's good info here about setting maven,soapui tests and jenkins up http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/22420 In comments at the bottom, you can see that jenkins will not recognize tests by default. Workaround is to use a freestyle project, but then we lose ability to have things like the 'perform maven release' button on the job. Have investigated this, seems to be an issue with hudson.maven.reporters.SurefireArchiver needing to have every plugin registered that it will consider test reports from. Since it's hardcoded into the file, guess the simplest way to fix this is to patch it to include the soapui plugin. Seems similar to this request for failsafe plugin: https://issues.jenkins-ci.org/browse/JENKINS-4229 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows
[
https://issues.jenkins-ci.org/browse/JENKINS-13417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163127#comment-163127
]
Lars Corneliussen commented on JENKINS-13417:
-
Same problem here - took me hours to find this...
Workaround: Downloaded 1.1.15 from
http://updates.jenkins-ci.org/download/plugins/git/, renamed to git.jpi, put
into JENKINS_HOME/plugins, then restarted - works fine.
git-plugin: rev-parse dereferencing tags breaks on Windows
--
Key: JENKINS-13417
URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin
git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof
The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
seems to break the git plugin for Windows, at least in some circumstances.
The syntax rev^{commit} gets mangled by cmd because ^ is a quote character.
This means that cmd passes rev{commit} to git, which as a cygwin executable
being run from Windows, further tries to do wildcard expansion and maps this
to revcommit. Putting around rev^{commit} empirically seems to work,
though I haven't tried it in the git plugin itself.
This C fragment:
{code}
#include stdio.h
int main(int argc, char* argv[])
{
int i;
for (i = 0; i argc; ++i)
{
printf(%s\n, argv[i]);
}
return 0;
}
{code}
when compiled with mingw to a native Windows application (a.exe) and invoked
from cmd as a.exe a^{b} prints a{b}. When the same fragment is compiled with
cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd,
it prints ab. Both print a^{b} when invoked from cmd as a.exe a^{b}.
I'm not sure what the fix is here other than perhaps detecting that this is
windows and putting quotes around the argument in Windows.
On another note, I left the Affects Version/s field blank. My Jenkins
installation claims that it is using version 1.1.6. Looking at the git repo
for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet
running strings on
plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class clearly shows
that my git plugin has that change in 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-13876) GNU Compiler Warnings also catches Java exception
Sylvestre Ledru created JENKINS-13876: - Summary: GNU Compiler Warnings also catches Java exception Key: JENKINS-13876 URL: https://issues.jenkins-ci.org/browse/JENKINS-13876 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Sylvestre Ledru Assignee: Ulli Hafner Priority: Minor Attachments: bug-warning.png With a project using both gcc and javac, the GNU Compiler Warnings catches also the Java warnings. CF screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13876) GNU Compiler Warnings also catches Java exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163128#comment-163128 ] Sylvestre Ledru commented on JENKINS-13876: --- I am available for testing if needed! GNU Compiler Warnings also catches Java exception -- Key: JENKINS-13876 URL: https://issues.jenkins-ci.org/browse/JENKINS-13876 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Sylvestre Ledru Assignee: Ulli Hafner Priority: Minor Attachments: bug-warning.png With a project using both gcc and javac, the GNU Compiler Warnings catches also the Java warnings. CF screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7997) Changelog read from JellyScript
[ https://issues.jenkins-ci.org/browse/JENKINS-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163129#comment-163129 ] Diptiman Adak commented on JENKINS-7997: I checked with groovy template here it is properSo problem remains in Jelly script onlyIn the ExtendedEmailPublisher.java also I printed the charset its coming UTF-8... Changelog read from JellyScript --- Key: JENKINS-7997 URL: https://issues.jenkins-ci.org/browse/JENKINS-7997 Project: Jenkins Issue Type: Bug Components: email-ext Affects Versions: current Environment: WindowsXP Reporter: ttaqt Priority: Critical Use the Jelly Script Template from version 2.9. I found that if SVN Checkin log has Chinese. It will show the Chinese as (鏇挎崲鍐欏箍鎾姛鑳藉尯鐨勮创鍥惧苟淇敼鍔ㄧ敾鐨勫疄鐜� . Is it the Jelly Script doesn`t support UTF-8? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13764) CVS authentication failure while running rlog command (Windows master / Unix slave)
[ https://issues.jenkins-ci.org/browse/JENKINS-13764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163130#comment-163130 ] Daniel Schaarschmidt commented on JENKINS-13764: The path I tried was: /home/myUser/.ssh/id_dsa I would certainly prefer to use ~ instead of home/myUser or using a placeholder like lklock, but I just tried the path that should have been easier to get working. Obviously that path won't work on the Windows master so I set one of the two Linux Nodes as parent using the Matrix Tie Parent plugin. CVS authentication failure while running rlog command (Windows master / Unix slave) --- Key: JENKINS-13764 URL: https://issues.jenkins-ci.org/browse/JENKINS-13764 Project: Jenkins Issue Type: Bug Components: cvs Affects Versions: current Environment: Jenkins 1.463 CVS Plugin 2.3 Master is running Windows, Slave is on Solaris Reporter: lklock I'm building on a Solaris slave trying to access a CVS repository over SSH connection Private key location is set to $SSH_PRIVATE_KEY_DIR/id_rsa and known hosts to $SSH_PRIVATE_KEY_DIR/known_hosts On the slave, SSH_PRIVATE_KEY_DIR is set to: /export/home/cxt2tst/.ssh Checkout is done properly: Building remotely on picard in workspace /export/home/cxt2tst/HUDSON/workspace/server.8.0 cvs update -d -P -r HEAD -D 14 May 2012 14:17:28 +0200 server.8.0 cvs update: Updating server.8.0 cvs update: Updating server.8.0/configuration but when it tries to get the ChangeLog, an exception is raised with the following stack trace FATAL: CVS authentication failure while running rlog command java.lang.RuntimeException: CVS authentication failure while running rlog command at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:530) at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:414) at hudson.scm.CVSSCM.checkout(CVSSCM.java:821) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.netbeans.lib.cvsclient.connection.AuthenticationException: SSH connection failed. at org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:134) at org.netbeans.lib.cvsclient.Client$1.run(Client.java:374) at java.lang.Thread.run(Unknown Source) Caused by: com.jcraft.jsch.JSchException: java.io.FileNotFoundException: \export\home\cxt2tst\.ssh\id_rsa (The system cannot find the path specified) at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:98) at com.jcraft.jsch.JSch.addIdentity(JSch.java:224) at com.jcraft.jsch.JSch.addIdentity(JSch.java:218) at org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:128) ... 2 more Caused by: java.io.FileNotFoundException: \export\home\cxt2tst\.ssh\id_rsa (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) at java.io.FileInputStream.init(Unknown Source) at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:83) ... 5 more It seems it cannot find the file due to the use of wrong path separator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13876) GNU Compiler Warnings also catches Java exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163131#comment-163131 ] Ulli Hafner commented on JENKINS-13876: --- I'm not sure if it is possible to decide if a warning is a Java or GNU warning. Do you have some example messages that I can use in a unit test? As workaround: pipe the output of javac (or gcc) to a file and use a separate parser configuration for that file. GNU Compiler Warnings also catches Java exception -- Key: JENKINS-13876 URL: https://issues.jenkins-ci.org/browse/JENKINS-13876 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Sylvestre Ledru Assignee: Ulli Hafner Priority: Minor Attachments: bug-warning.png With a project using both gcc and javac, the GNU Compiler Warnings catches also the Java warnings. CF screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13876) GNU Compiler Warnings also catches Java exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163132#comment-163132 ] Sylvestre Ledru commented on JENKINS-13876: --- Thanks for the super quick answer! Here is an example of a warning cough by warnings: ./modules/completion/src/java/org/scilab/modules/completion/AbstractSciCompletionWindow.java:40: error: package com.artenum.rosetta.ui does not exist Maybe reject \.java from the regexp ? GNU Compiler Warnings also catches Java exception -- Key: JENKINS-13876 URL: https://issues.jenkins-ci.org/browse/JENKINS-13876 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Sylvestre Ledru Assignee: Ulli Hafner Priority: Minor Attachments: bug-warning.png With a project using both gcc and javac, the GNU Compiler Warnings catches also the Java warnings. CF screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13877) Cobertura plugin does not provide data to the REST API
Joey W created JENKINS-13877:
Summary: Cobertura plugin does not provide data to the REST API
Key: JENKINS-13877
URL: https://issues.jenkins-ci.org/browse/JENKINS-13877
Project: Jenkins
Issue Type: Bug
Components: cobertura
Reporter: Joey W
Assignee: stephenconnolly
Priority: Minor
Accessing data from the Cobertura plugin via the REST API is not possible.
Hitting the URL http://jenkins/job/name/build/cobertura/api/xml gives:
coverageResultresults//coverageResult
and .../api/json gives:
{ results: { } }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13846) Upstream filter does not show all dependencies
[ https://issues.jenkins-ci.org/browse/JENKINS-13846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Robertson resolved JENKINS-13846. --- Resolution: Fixed look for this fix in version 1.21 Upstream filter does not show all dependencies -- Key: JENKINS-13846 URL: https://issues.jenkins-ci.org/browse/JENKINS-13846 Project: Jenkins Issue Type: Bug Components: view-job-filters Affects Versions: current Environment: Debian Reporter: Thorsten Roemer Assignee: Jacob Robertson Priority: Minor Fix For: current When using the upstream/downstram jobs filter the view does not show all dependencies. It looks like the view contains only the entries found in the job's configuration under Build after other projects are built Build other projects? On the job's status page, the upstream projects downstream projects sections contain much more dependencies. It looks like the missing ones are the maven dependencies, calculated on-the-fly by jenkins? These dependencies should be included in the view 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-13878) [Max # of builds to keep] can't be configured as global variable
Neven Radovanovic created JENKINS-13878: --- Summary: [Max # of builds to keep] can't be configured as global variable Key: JENKINS-13878 URL: https://issues.jenkins-ci.org/browse/JENKINS-13878 Project: Jenkins Issue Type: Bug Components: gui Affects Versions: current Environment: Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: d:\fspldev\java\jdk1.6.0_27-i586 Default locale: en_US, platform encoding: Cp1252 OS name: windows xp, version: 5.1, arch: x86, family: windows Jenkins ver. 1.465 Reporter: Neven Radovanovic It would be very helpful to configure [Max # of builds to keep] as a [Global property] that can be applied to several jobs at once for easy maintenance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163134#comment-163134 ] Valentin Batz commented on JENKINS-13264: -- I've experienced the same issue and traced it down to a cvsnt inconvenience. I'll try to explain my findings. The -d argument gets passed to the server. The server process creates a local copy in a tmp dir for the checkout with that argument as name. It does not create the required subdirectories and thats why the checkout will fail. I assume your cvsnt/cvs server is running in a unix environment, because works with backslashes because backslashes are valid in unix filenames/directories, and the first level directory is created in the tmpdir. I suggest not to pass the -d argument to the server, when doing 'partial checkouts' with subdirs. I'd rather suggest to implement a client-side redirection of the files/directories. fail checkout 2 modules with different path --- Key: JENKINS-13264 URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 Project: Jenkins Issue Type: Bug Components: cvs Environment: linux Reporter: Eric Co Assignee: Michael Clarke Fix For: current I create two cvs modules with the path lib/flac-1.2.1 drv/linux/fuse when it check out, got the error: cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 lib/flac-1.2.1 cvs [checkout aborted]: could not change directory to requested checkout directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163134#comment-163134 ] Valentin Batz edited comment on JENKINS-13264 at 5/23/12 3:58 PM: --- I've experienced the same issue and traced it down to a cvsnt inconvenience. I'll try to explain my findings. The -d argument gets passed to the server. The server process creates a local copy in a tmp dir for the checkout with that argument as name. It does not create the required subdirectories and thats why the checkout will fail. I assume your cvsnt/cvs server is running in a unix environment, because it works with backslashes for you. I've discovered the same workaround. It's working because backslashes are valid in unix filenames/directories, and the first level directory is created in the tmpdir. I suggest not to pass the -d argument to the server, when doing 'partial checkouts' with subdirs. I'd rather suggest to implement a client-side redirection of the files/directories. was (Author: valeni): I've experienced the same issue and traced it down to a cvsnt inconvenience. I'll try to explain my findings. The -d argument gets passed to the server. The server process creates a local copy in a tmp dir for the checkout with that argument as name. It does not create the required subdirectories and thats why the checkout will fail. I assume your cvsnt/cvs server is running in a unix environment, because works with backslashes because backslashes are valid in unix filenames/directories, and the first level directory is created in the tmpdir. I suggest not to pass the -d argument to the server, when doing 'partial checkouts' with subdirs. I'd rather suggest to implement a client-side redirection of the files/directories. fail checkout 2 modules with different path --- Key: JENKINS-13264 URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 Project: Jenkins Issue Type: Bug Components: cvs Environment: linux Reporter: Eric Co Assignee: Michael Clarke Fix For: current I create two cvs modules with the path lib/flac-1.2.1 drv/linux/fuse when it check out, got the error: cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 lib/flac-1.2.1 cvs [checkout aborted]: could not change directory to requested checkout directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13876) GNU Compiler Warnings also catches Java exception
[ https://issues.jenkins-ci.org/browse/JENKINS-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163135#comment-163135 ] Ulli Hafner commented on JENKINS-13876: --- Well, that does not work in general. So I think I can't do anything in code here. You need to apply the workaround. I.e. Java parsers scans console and GCC parser scans a file (or vice versa). GNU Compiler Warnings also catches Java exception -- Key: JENKINS-13876 URL: https://issues.jenkins-ci.org/browse/JENKINS-13876 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Sylvestre Ledru Assignee: Ulli Hafner Priority: Minor Attachments: bug-warning.png With a project using both gcc and javac, the GNU Compiler Warnings catches also the Java warnings. CF screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13468) Would like to create/use a central catalog . . .
[ https://issues.jenkins-ci.org/browse/JENKINS-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163136#comment-163136 ] Frank Merrow commented on JENKINS-13468: This issue finally bubbled up back into view . . . I've tried it and the scripts directory will do nicely, thank you . . . on a couple of our Jenkins, Jenkins got installed in C:\Program File (x86) which causes some access issues if the user is not running CMD.EXE as Admin . . . but other than that minor annoyance, this solution is very usable for my situation. THANK YOU. Frank Would like to create/use a central catalog . . . -- Key: JENKINS-13468 URL: https://issues.jenkins-ci.org/browse/JENKINS-13468 Project: Jenkins Issue Type: New Feature Components: scriptler Environment: Windows . . . Reporter: Frank Merrow Assignee: domi We have a large and growing number of Jenkins instances . . . We don't have many Groovy script, but rather than carrying them around by hand, it would be nice to be able to put them in once place (network share for instance) and access them from any Jenkins. Note this isn't exactly like your public repositories, because I don't want to have to import them . . . while certain scripts might be local to a given Jenkins, for the global Jenkins script . . . if they are changed in one Jenkins, I would like that update to appear for all Jenkins attached to the repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7978) Variable substitution in Buckminster script file not respected
[
https://issues.jenkins-ci.org/browse/JENKINS-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163137#comment-163137
]
Lorenzo Bettini commented on JENKINS-7978:
--
even with ${env_var:WORKSPACE} it still does not work...
Variable substitution in Buckminster script file not respected
--
Key: JENKINS-7978
URL: https://issues.jenkins-ci.org/browse/JENKINS-7978
Project: Jenkins
Issue Type: Bug
Components: buckminster
Affects Versions: current
Environment: Windows7
Reporter: aewallace
Assignee: jutzig
When I used a script file including my Buckminster commands instead of
entering the commands directly into the Buckminster command text area
variable substitution does not appear to be respected.
Thus, if I use something like ${WORKSPACE}/pathToSomething in the command
enterted directly in the Buckminster text area , then the ${WORKSPACE}
variable is substituted correctly to the Hudson workspace for the current
job. However, if I use the same variable within my Buckminster script file,
then a blank string is substituted instead when the command is run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
Jeremy Frank created JENKINS-13879: -- Summary: Builds failing to trigger due to changelist number being set incorrectly Key: JENKINS-13879 URL: https://issues.jenkins-ci.org/browse/JENKINS-13879 Project: Jenkins Issue Type: Bug Components: perforce Environment: Jenkins 1.462, Perforce plugin 1.3.13 Reporter: Jeremy Frank When a job is run, the Perforce plugin for Jenkins records a changelist number for the build instance. From that point forward, triggering additional builds via Perforce only happens when new changelists are submitted with numbers higher than the recorded changelist number. Great, except that the recorded changelist number may not be correct. For example, if the most recent changelists look like this (from p4 changelists -m 2): Change 24083 on 2012/05/23 by rmercer@rmercer-DcsMain *pending* 'The adapter layer now returns D' Change 24082 on 2012/05/23 by reladmin@jenkins-aci-RILCinterion-QA-2 'Check in server build result fo' and a build starts (either via the Build Now button, or because of 24082 being submitted), the Perforce plugin runs p4 counter change and records 24083 as the changelist number. Note that 24083 is a *pending* changelist. Further polling will fail to detect that 24083 was submitted. No build will result. Oops, the latest reserved changelist number was recorded, rather than the latest submitted changelist number. Often this problem is masked because new changelist numbers get generated upon a checkin, but not always. Perforce only renumbers a changelist upon checkin if there are intervening changelists. Suggested solution: Rather than using p4 counter change to detect the current changelist number, please use p4 changelists -m 1 -s submitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13878) [Max # of builds to keep] can't be configured as global variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe updated JENKINS-13878: - Issue Type: Improvement (was: Bug) [Max # of builds to keep] can't be configured as global variable Key: JENKINS-13878 URL: https://issues.jenkins-ci.org/browse/JENKINS-13878 Project: Jenkins Issue Type: Improvement Components: gui Affects Versions: current Environment: Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: d:\fspldev\java\jdk1.6.0_27-i586 Default locale: en_US, platform encoding: Cp1252 OS name: windows xp, version: 5.1, arch: x86, family: windows Jenkins ver. 1.465 Reporter: Neven Radovanovic It would be very helpful to configure [Max # of builds to keep] as a [Global property] that can be applied to several jobs at once for easy maintenance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13743) Jenkins 1.463 + Klocwork plugin - crashes when saving configuration
[
https://issues.jenkins-ci.org/browse/JENKINS-13743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Boissinot resolved JENKINS-13743.
-
Resolution: Fixed
Jenkins 1.463 + Klocwork plugin - crashes when saving configuration
---
Key: JENKINS-13743
URL: https://issues.jenkins-ci.org/browse/JENKINS-13743
Project: Jenkins
Issue Type: Bug
Components: klocwork
Affects Versions: current
Environment: RHEL 5.5, master node on Linux
Reporter: Waldek M
Assignee: Gregory Boissinot
Priority: Blocker
Attachments: jenkins_fail.txt
After upgrade of Jenkins to 1.463, I'm having crashes each time I try to edit
configuration of jobs.
This didn't stop when downgraded Klocwork plugin from 1.7 to 1.2.
Issue disappeared when downgraded Jenkins from 1.463 to 1.462
Attaching the full stacktrace as file.
===
Stacktrace:
java.lang.IllegalArgumentException: Failed to instantiate class
com.thalesgroup.hudson.plugins.klocwork.config.KloConfig from
{buildXSize:0,buildYSize:0,displayAllError:false,displayHighSeverity:false,displayLowSeverity:false,displayMedSeverity:false,existing:false,failureThreshold:,fixed:false,healthy:,highSeverity:false,interval:1,kind:com.thalesgroup.hudson.plugins.klocwork.KloPublisher,klocworkReportPattern:,linkBuildLog:false,linkParseLog:false,linkReview:true,lowSeverity:false,newFailureThreshold:,newThreshold:,neww:false,publishBuildGraph:false,publishProjectGraph:false,stapler-class:com.thalesgroup.hudson.plugins.klocwork.KloPublisher,threshold:,trendNum:0,trendXSize:0,trendYSize:0,unHealthy:}
at
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:373)
at
com.thalesgroup.hudson.plugins.klocwork.KloPublisher$KloDescriptor.newInstance(KloPublisher.java:253)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13429) Nested views not showing up with just read perms for View
[ https://issues.jenkins-ci.org/browse/JENKINS-13429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163139#comment-163139 ] Vincent Latombe commented on JENKINS-13429: --- It will be in 1.467 Nested views not showing up with just read perms for View - Key: JENKINS-13429 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429 Project: Jenkins Issue Type: Bug Components: nested-view Affects Versions: current Reporter: M S Assignee: Kohsuke Kawaguchi Labels: jenkins, plugin, views Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 1.1.2 User has read permissions for View but Jenkins main page is missing Nested views (even if they have sub views with jobs). Adding configure perms for View results in Nested views showing up correctly. It looks like it's connected with: Added the View.READ permission to control visibility of views, and updated the default implementation to hide empty views. (issue 3681) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13880) Ability to run script when discarding build (or build artifacts)
[ https://issues.jenkins-ci.org/browse/JENKINS-13880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163140#comment-163140 ] Gregory Boissinot commented on JENKINS-13880: - Maybe look at the ArtifactDeployer Jenkins plugin (https://wiki.jenkins-ci.org/display/JENKINS/ArtifactDeployer+Plugin). You are able to deploy generated artifacts from workspace to remote locations and enable you to run a script when the build job is discarded. Ability to run script when discarding build (or build artifacts) Key: JENKINS-13880 URL: https://issues.jenkins-ci.org/browse/JENKINS-13880 Project: Jenkins Issue Type: New Feature Components: core Affects Versions: current Reporter: John Myers We would like the ability to configure a script to be run when a build is discarded (or possibly when build artifacts are discarded). We are using a script build step to push a generated RPM into a yum repository. We need a way to delete old RPMs in order to save space, yet keep the RPMs of builds that are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13881) Custom application command itestcli is not working ...
udaya shanakr created JENKINS-13881: --- Summary: Custom application command itestcli is not working ... Key: JENKINS-13881 URL: https://issues.jenkins-ci.org/browse/JENKINS-13881 Project: Jenkins Issue Type: Bug Components: batch-task Affects Versions: current Environment: Windows 7 Reporter: udaya shanakr Assignee: Kohsuke Kawaguchi Attachments: cmd.jpg, jenkins.jpg I have a custom application called iTest and it could be run from command prompt using command itestcli. the command is running fine either from cmd or batch file defined. But when I am running from Jenkins it is failing to run. I have tried with various default commands like dir,ipconfig these are running fine. Any suggestion could be appreciate a lot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13865) Jenkins /queue/api does not produce properly formatted JSON when a build in queue where the destination node/s are busy.
[
https://issues.jenkins-ci.org/browse/JENKINS-13865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163141#comment-163141
]
Jason Howk commented on JENKINS-13865:
--
Looks like the issue was due to commit ff4b0255 where description was, Added
another hyperlink to the console output of a blocked matrix build
configuration.
Jenkins /queue/api does not produce properly formatted JSON when a build in
queue where the destination node/s are busy.
Key: JENKINS-13865
URL: https://issues.jenkins-ci.org/browse/JENKINS-13865
Project: Jenkins
Issue Type: Bug
Components: core
Affects Versions: current
Environment: Linux
Reporter: Jason Howk
Jenkins /queue/api does not produce properly formatted JSON when build in
queue where a node/s are fully busy. The json produced is un-parsable. This
can be visible on the builds.apache.org server.
Example:
why:Waiting for next available executor on
{noformat}
[8mha:kB+LCABb85aBtbiIQSajNKU4P08vOT+vOD8nVc+jsiC1KCczL9svvyT1dMUiOWdZ/mImBiZPBrac1Lz0kgwfBubSopwSBiGfrMSyRP2cxLx0/eCSosy8dOuKIgYpNOOcITTIMAYIYGRiYKgoADLYShgE9JPzcwtKS1KL9HNKk1PzUgENqikilQ==[0mlucene
{noformat}
Appears that the why property of the queued build isn't being formatted
properly. Actually it's being gzipped...
Looking at the source, the hudson.model.queue.CauseOfBlockage class appears
to be the culprit. To wit:
{noformat}
public String getShortDescription() {
return
Messages.Queue_WaitingForNextAvailableExecutorOn(HyperlinkNote.encodeTo(/computer/+
node.getNodeName(), node.getNodeName()));
}
{noformat}
The nodename is attempting to be encoded with HyperlinkNote:
{noformat}
public static String encodeTo(String url, String text) {
try {
return new HyperlinkNote(url,text.length()).encode()+text;
} catch (IOException e) {
// impossible, but don't make this a fatal problem
LOGGER.log(Level.WARNING, Failed to serialize
+HyperlinkNote.class,e);
return text;
}
}
{noformat}
Which calls the supers encode() method:
{noformat}
public String encode() throws IOException {
return encodeToBytes().toString();
}
{noformat}
And finally encodeToBytes():
{noformat}
private ByteArrayOutputStream encodeToBytes() throws IOException {
ByteArrayOutputStream buf = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(new
GZIPOutputStream(buf));
oos.writeObject(this);
oos.close();
ByteArrayOutputStream buf2 = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(new
Base64OutputStream(buf2,true,-1,null));
buf2.write(PREAMBLE);
dos.writeInt(buf.size());
buf.writeTo(dos);
dos.close();
buf2.write(POSTAMBLE);
return buf2;
}
{noformat}
Finally in ConsoleNote
{noformat}
public static final String PREAMBLE_STR = \u001B[8mha:;
public static final String POSTAMBLE_STR = \u001B[0m;
}
{noformat}
Clearly the choice in using ansi escaping, and therefore the brackets is
violating the JSON structural syntax rules and causing the JSON emitted to be
un-parsable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13882) Configure Jenkins to connect to Remote CVS
[ https://issues.jenkins-ci.org/browse/JENKINS-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Configure Jenkins to connect to Remote CVS -- Key: JENKINS-13882 URL: https://issues.jenkins-ci.org/browse/JENKINS-13882 Project: Jenkins Issue Type: Task Components: cvs Environment: Deployed Jenkins on IBM WAS 7.0.015 which is on windows machine. CVS is on a different Unix machine. Reporter: Vinod Bajjuri Labels: jenkins I'm not sure where to post this question. I have successfully installed latest Jenkins on IBM WAS 7.0.0.15(which is on windows machine). Now, 1) How do I configure the Jenkins to connect to CVS which is on a remote unix machine? 2) Also, is it possible to launch a shell script, which calls an 'ant' command, that is on a remote unix server? Any help would be appreciated. Thank You, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13882) Configure Jenkins to connect to Remote CVS
[ https://issues.jenkins-ci.org/browse/JENKINS-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13882 stopped by Vinod Bajjuri. Configure Jenkins to connect to Remote CVS -- Key: JENKINS-13882 URL: https://issues.jenkins-ci.org/browse/JENKINS-13882 Project: Jenkins Issue Type: Task Components: cvs Environment: Deployed Jenkins on IBM WAS 7.0.015 which is on windows machine. CVS is on a different Unix machine. Reporter: Vinod Bajjuri Labels: jenkins I'm not sure where to post this question. I have successfully installed latest Jenkins on IBM WAS 7.0.0.15(which is on windows machine). Now, 1) How do I configure the Jenkins to connect to CVS which is on a remote unix machine? 2) Also, is it possible to launch a shell script, which calls an 'ant' command, that is on a remote unix server? Any help would be appreciated. Thank You, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13882) Configure Jenkins to connect to Remote CVS
Vinod Bajjuri created JENKINS-13882: --- Summary: Configure Jenkins to connect to Remote CVS Key: JENKINS-13882 URL: https://issues.jenkins-ci.org/browse/JENKINS-13882 Project: Jenkins Issue Type: Task Components: cvs Environment: Deployed Jenkins on IBM WAS 7.0.015 which is on windows machine. CVS is on a different Unix machine. Reporter: Vinod Bajjuri I'm not sure where to post this question. I have successfully installed latest Jenkins on IBM WAS 7.0.0.15(which is on windows machine). Now, 1) How do I configure the Jenkins to connect to CVS which is on a remote unix machine? 2) Also, is it possible to launch a shell script, which calls an 'ant' command, that is on a remote unix server? Any help would be appreciated. Thank You, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13882) Configure Jenkins to connect to Remote CVS
[ https://issues.jenkins-ci.org/browse/JENKINS-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Bajjuri reassigned JENKINS-13882: --- Assignee: Kohsuke Kawaguchi Configure Jenkins to connect to Remote CVS -- Key: JENKINS-13882 URL: https://issues.jenkins-ci.org/browse/JENKINS-13882 Project: Jenkins Issue Type: Task Components: cvs Environment: Deployed Jenkins on IBM WAS 7.0.015 which is on windows machine. CVS is on a different Unix machine. Reporter: Vinod Bajjuri Assignee: Kohsuke Kawaguchi Labels: jenkins I'm not sure where to post this question. I have successfully installed latest Jenkins on IBM WAS 7.0.0.15(which is on windows machine). Now, 1) How do I configure the Jenkins to connect to CVS which is on a remote unix machine? 2) Also, is it possible to launch a shell script, which calls an 'ant' command, that is on a remote unix server? Any help would be appreciated. Thank You, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
[ https://issues.jenkins-ci.org/browse/JENKINS-13879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti reassigned JENKINS-13879: --- Assignee: Rob Petti Builds failing to trigger due to changelist number being set incorrectly Key: JENKINS-13879 URL: https://issues.jenkins-ci.org/browse/JENKINS-13879 Project: Jenkins Issue Type: Bug Components: perforce Environment: Jenkins 1.462, Perforce plugin 1.3.13 Reporter: Jeremy Frank Assignee: Rob Petti When a job is run, the Perforce plugin for Jenkins records a changelist number for the build instance. From that point forward, triggering additional builds via Perforce only happens when new changelists are submitted with numbers higher than the recorded changelist number. Great, except that the recorded changelist number may not be correct. For example, if the most recent changelists look like this (from p4 changelists -m 2): Change 24083 on 2012/05/23 by rmercer@rmercer-DcsMain *pending* 'The adapter layer now returns D' Change 24082 on 2012/05/23 by reladmin@jenkins-aci-RILCinterion-QA-2 'Check in server build result fo' and a build starts (either via the Build Now button, or because of 24082 being submitted), the Perforce plugin runs p4 counter change and records 24083 as the changelist number. Note that 24083 is a *pending* changelist. Further polling will fail to detect that 24083 was submitted. No build will result. Oops, the latest reserved changelist number was recorded, rather than the latest submitted changelist number. Often this problem is masked because new changelist numbers get generated upon a checkin, but not always. Perforce only renumbers a changelist upon checkin if there are intervening changelists. Suggested solution: Rather than using p4 counter change to detect the current changelist number, please use p4 changelists -m 1 -s submitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
[
https://issues.jenkins-ci.org/browse/JENKINS-13879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163142#comment-163142
]
Rob Petti commented on JENKINS-13879:
-
It already uses 'p4 changes -m 1 -s'. 'p4 counter change' is only used when
looking for the actual latest change in the workspace. Here's an example from
one of my own build logs:
{code}
[workspace] $ p4 counter change
[workspace] $ p4 -s changes -s submitted //installer/...@260018,@260111
[workspace] $ p4 describe -s 260103
...
Sync'ing workspace to changelist 260103.
[workspace] $ p4 -s sync //installer/...@260103
{code}
'p4 counter change' returns 260111, but as you can see, it's using the last
changeset that was submitted in the view for syncing.
In the cases where you've seen different behavior, were there any changes made
at all? I suspect it may be falling back onto the value provided by the counter
when there are no changes available in the view, which is of course incorrect
behavior.
Builds failing to trigger due to changelist number being set incorrectly
Key: JENKINS-13879
URL: https://issues.jenkins-ci.org/browse/JENKINS-13879
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: Jenkins 1.462, Perforce plugin 1.3.13
Reporter: Jeremy Frank
When a job is run, the Perforce plugin for Jenkins records a changelist
number for the build instance. From that point forward, triggering additional
builds via Perforce only happens when new changelists are submitted with
numbers higher than the recorded changelist number. Great, except that the
recorded changelist number may not be correct.
For example, if the most recent changelists look like this (from p4
changelists -m 2):
Change 24083 on 2012/05/23 by rmercer@rmercer-DcsMain *pending* 'The
adapter layer now returns D'
Change 24082 on 2012/05/23 by reladmin@jenkins-aci-RILCinterion-QA-2
'Check in server build result fo'
and a build starts (either via the Build Now button, or because of 24082
being submitted), the Perforce plugin runs p4 counter change and records
24083 as the changelist number. Note that 24083 is a *pending* changelist.
Further polling will fail to detect that 24083 was submitted. No build will
result. Oops, the latest reserved changelist number was recorded, rather
than the latest submitted changelist number.
Often this problem is masked because new changelist numbers get generated
upon a checkin, but not always. Perforce only renumbers a changelist upon
checkin if there are intervening changelists.
Suggested solution: Rather than using p4 counter change to detect the
current changelist number, please use p4 changelists -m 1 -s submitted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12095) Violations plugin not reporting fxcop details
[ https://issues.jenkins-ci.org/browse/JENKINS-12095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163143#comment-163143 ] Gregory Nofi commented on JENKINS-12095: I'm also seeing this, but for pep8 and pylint. I'm not sure if it's related but pep8/pylint per-file view worked before upgrading to 0.7.10. Violations plugin not reporting fxcop details - Key: JENKINS-12095 URL: https://issues.jenkins-ci.org/browse/JENKINS-12095 Project: Jenkins Issue Type: Bug Components: violations Affects Versions: current Environment: Jenkins v 1.440 on Windows Server 2008 / Violations Plugin 0.7.10 Reporter: Nick Schneider Assignee: peterkittreilly Labels: plugin Fix For: current Attachments: jenkins-screenshot.jpg I'm building a .NET script in which I have a post build step executing a windows batch command: fxcopcmd /file:HelloWorld\bin\HelloWorld.dll /out:fxcop-report.xml /s exit 0 I have check the 'Violations' option and next to the fxcop XML filename pattern, I have placed 'fxcop-report.xml' After the build I know there were 14 violations placed in the xml file, but I'm not seeing any results in the graph view of the violations, and when I click on the graph it doesn't even specify out that fxcop was picked up (see screenshot). UPDATE: This only affects a maven 2/3 project. If I build a free-style project, I get the violations to show up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13336) Invalid JSON is produced during remote api operations when a changeSet contains duplicate keys.
[ https://issues.jenkins-ci.org/browse/JENKINS-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163144#comment-163144 ] Jason Howk commented on JENKINS-13336: -- This looks like it was fixed in f65c3484 which was release in 1.458. I don't see duplicates anymore on 1.467... Invalid JSON is produced during remote api operations when a changeSet contains duplicate keys. --- Key: JENKINS-13336 URL: https://issues.jenkins-ci.org/browse/JENKINS-13336 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Jenkins Version 1.458 on Linux (centos). Also appears in 1.457 Reporter: Jason Howk Priority: Critical Use this URL as a working example: http://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/1637/api/json When looking at a specific build for a given job, the JSON produced for the Remote API functionality is invalid when the changeSet is not null. Using the example above, the JSON returned from this api call results in the changeSet object containing two author and msg objects. These duplicate keys are causing errors with external parsers that are downloading data using the api. Steps to reproduce: 1.) Using the URL above, attempt to validate the JSON using JSLint (www.jslint.com) 2.) You will receive a duplicate 'author' and 'msg' error. 3.) Using a build that does not have a changeSet does not contain the duplicates and therefore produces valid JSON. https://builds.apache.org/job/ActiveMQ/918/api/json can also be used (Jenkins 1.457) to verify. A duplicate changeSet/items/msg will be found. Expected result: 1.) Data should validate properly (and therefore parse.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13336) Invalid JSON is produced during remote api operations when a changeSet contains duplicate keys.
[ https://issues.jenkins-ci.org/browse/JENKINS-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163144#comment-163144 ] Jason Howk edited comment on JENKINS-13336 at 5/23/12 10:34 PM: This looks like it was fixed in f65c3484. I don't see duplicates anymore on 1.467. was (Author: flyingfish): This looks like it was fixed in f65c3484 which was release in 1.458. I don't see duplicates anymore on 1.467... Invalid JSON is produced during remote api operations when a changeSet contains duplicate keys. --- Key: JENKINS-13336 URL: https://issues.jenkins-ci.org/browse/JENKINS-13336 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Jenkins Version 1.458 on Linux (centos). Also appears in 1.457 Reporter: Jason Howk Priority: Critical Use this URL as a working example: http://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/1637/api/json When looking at a specific build for a given job, the JSON produced for the Remote API functionality is invalid when the changeSet is not null. Using the example above, the JSON returned from this api call results in the changeSet object containing two author and msg objects. These duplicate keys are causing errors with external parsers that are downloading data using the api. Steps to reproduce: 1.) Using the URL above, attempt to validate the JSON using JSLint (www.jslint.com) 2.) You will receive a duplicate 'author' and 'msg' error. 3.) Using a build that does not have a changeSet does not contain the duplicates and therefore produces valid JSON. https://builds.apache.org/job/ActiveMQ/918/api/json can also be used (Jenkins 1.457) to verify. A duplicate changeSet/items/msg will be found. Expected result: 1.) Data should validate properly (and therefore parse.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13883) Support option to omit cleaning
Greg Temchenko created JENKINS-13883:
Summary: Support option to omit cleaning
Key: JENKINS-13883
URL: https://issues.jenkins-ci.org/browse/JENKINS-13883
Project: Jenkins
Issue Type: Improvement
Components: mercurial
Reporter: Greg Temchenko
Assignee: Kohsuke Kawaguchi
Currently there's an option Clean Build that does some extra cleaning
{code:java}
// file: ./src/main/java/hudson/plugins/mercurial/MercurialSCM.java
if(clean) {
if (hg.cleanAll().pwd(repository).join() != 0) {
listener.error(Failed to clean unversioned files);
throw new AbortException(Failed to clean unversioned files);
}
}
{code}
But if this option isn't checked the plugin still clean all local modifications
cause it calls hg update with --clean option.
{code}
// file: ./src/main/java/hudson/plugins/mercurial/MercurialSCM.java
updateExitCode = hg.run(update, --clean, --rev,
getBranch(env)).pwd(repository).join();
{code}
It would be useful to have an option not cleaning local modifications. If it's
possible to do so when Clean Build unchecked it looks pretty simple to
implement. But I'm not sure it's a proper way to do that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13581) Race condition between RetentionStrategy and Executor
[
https://issues.jenkins-ci.org/browse/JENKINS-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163146#comment-163146
]
Arvind Ramalingam commented on JENKINS-13581:
-
Any Fix on this one.I have recently updated my version to 1.447.1 and the build
is successful but it still hangs on the executor for hours.Please provide a fix
for this.
Race condition between RetentionStrategy and Executor
-
Key: JENKINS-13581
URL: https://issues.jenkins-ci.org/browse/JENKINS-13581
Project: Jenkins
Issue Type: Bug
Components: core
Reporter: Kohsuke Kawaguchi
{{RetentionStrategy}} doesn't really get any stop-the-world consistent view
of the world when it makes a decision to terminate the node, and from there
to the actual termination of the node, the rest of the world can also change.
More specifically, an {{Executor}} can go from idle to busy.
This ends up aborting the build that's newly started, as the node is removed
and executors interrupted. This isn't a fatal problem, but it's an annoyance.
Because we generally do not restrict how {{RetentionStrategy}} makes a
decision, we cannot really stop the world for it. But it seems prudent to
hold executors still (at least no idle-busy transition) while the check is
done --- either the core will do so before calling into the {{check}} method,
or make it easy for {{RetentionStrategy}} to do so if it wants.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13884) Race Condition in stable version 1.447.1|Critical Blocker
Arvind Ramalingam created JENKINS-13884: --- Summary: Race Condition in stable version 1.447.1|Critical Blocker Key: JENKINS-13884 URL: https://issues.jenkins-ci.org/browse/JENKINS-13884 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Production Reporter: Arvind Ramalingam Priority: Blocker I have upgraded my version of Jenkins to 1.447.1 and Jobs are hanging on executors for hours even though the jobs have been successful.For ex job A build 1 ,build 2 and build 3 show up on the executor running for hours and when I check Job A builds 1 and 2 are already done.Please let me know how to fix this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13885) Failures not copied when path contains whitespaces
Paul Eipper created JENKINS-13885:
-
Summary: Failures not copied when path contains whitespaces
Key: JENKINS-13885
URL: https://issues.jenkins-ci.org/browse/JENKINS-13885
Project: Jenkins
Issue Type: Bug
Components: clang-scanbuild
Affects Versions: current
Reporter: Paul Eipper
Assignee: Josh Kennedy
The scan-build step fails to write to paths that contain spaces:
{code}
EXECUTING COMMAND:[/Volumes/Overmind HD/Jenkins/checker-264/scan-build, -k, -v,
-v, -o, /Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports, xcodebuild, -target,
ProjectExample, -configuration, Debug, -sdk, iphonesimulator, clean, build]
[workspace] $ /Volumes/Overmind HD/Jenkins/checker-264/scan-build -k -v -v -o
/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports xcodebuild -target
ProjectExample -configuration Debug -sdk iphonesimulator clean build
scan-build: Emitting reports for this run to '/Volumes/Overmind
HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1'.
(...)
scan-build: 0 bugs found.
scan-build: The analyzer encountered problems on some source files.
scan-build: Preprocessed versions of these sources were deposited in
'/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures'.
scan-build: Please consider submitting a bug report using these files:
scan-build: http://clang-analyzer.llvm.org/filing_bugs.html
{code}
Checking /Volumes after the build there is an file named Overmind containing
various scan-build path error related messages, as in:
{code}
usage: uname [-amnprsv]
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
clang: error: no such file or directory: 'HD/Jenkins/Home/jobs/Project'
clang: error: no such file or directory:
'Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures/clang_other_error_khPht3.mi.info.txt'
(...)
{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-13885) Failures not copied when path contains whitespaces
[
https://issues.jenkins-ci.org/browse/JENKINS-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Eipper updated JENKINS-13885:
--
Description:
The scan-build step fails to write to paths that contain spaces.
From the build log:
{noformat}
EXECUTING COMMAND:[/Volumes/Overmind HD/Jenkins/checker-264/scan-build, -k, -v,
-v, -o, /Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports, xcodebuild, -target,
ProjectExample, -configuration, Debug, -sdk, iphonesimulator, clean, build]
[workspace] $ /Volumes/Overmind HD/Jenkins/checker-264/scan-build -k -v -v -o
/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports xcodebuild -target
ProjectExample -configuration Debug -sdk iphonesimulator clean build
scan-build: Emitting reports for this run to '/Volumes/Overmind
HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1'.
(...)
scan-build: 0 bugs found.
scan-build: The analyzer encountered problems on some source files.
scan-build: Preprocessed versions of these sources were deposited in
'/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures'.
scan-build: Please consider submitting a bug report using these files:
scan-build: http://clang-analyzer.llvm.org/filing_bugs.html
{noformat}
Checking /Volumes after the build there is a file named Overmind containing
various scan-build path error related messages, as in:
{noformat}
usage: uname [-amnprsv]
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
clang: error: no such file or directory: 'HD/Jenkins/Home/jobs/Project'
clang: error: no such file or directory:
'Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures/clang_other_error_khPht3.mi.info.txt'
(...)
{noformat}
was:
The scan-build step fails to write to paths that contain spaces:
{code}
EXECUTING COMMAND:[/Volumes/Overmind HD/Jenkins/checker-264/scan-build, -k, -v,
-v, -o, /Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports, xcodebuild, -target,
ProjectExample, -configuration, Debug, -sdk, iphonesimulator, clean, build]
[workspace] $ /Volumes/Overmind HD/Jenkins/checker-264/scan-build -k -v -v -o
/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports xcodebuild -target
ProjectExample -configuration Debug -sdk iphonesimulator clean build
scan-build: Emitting reports for this run to '/Volumes/Overmind
HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1'.
(...)
scan-build: 0 bugs found.
scan-build: The analyzer encountered problems on some source files.
scan-build: Preprocessed versions of these sources were deposited in
'/Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures'.
scan-build: Please consider submitting a bug report using these files:
scan-build: http://clang-analyzer.llvm.org/filing_bugs.html
{code}
Checking /Volumes after the build there is an file named Overmind containing
various scan-build path error related messages, as in:
{code}
usage: uname [-amnprsv]
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
clang: error: no such file or directory: 'HD/Jenkins/Home/jobs/Project'
clang: error: no such file or directory:
'Example-Develop/workspace/clangScanBuildReports/2012-05-23-1/failures/clang_other_error_khPht3.mi.info.txt'
(...)
{code}
Failures not copied when path contains whitespaces
--
Key: JENKINS-13885
URL: https://issues.jenkins-ci.org/browse/JENKINS-13885
Project: Jenkins
Issue Type: Bug
Components: clang-scanbuild
Affects Versions: current
Reporter: Paul Eipper
Assignee: Josh Kennedy
The scan-build step fails to write to paths that contain spaces.
From the build log:
{noformat}
EXECUTING COMMAND:[/Volumes/Overmind HD/Jenkins/checker-264/scan-build, -k,
-v, -v, -o, /Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports, xcodebuild, -target,
ProjectExample, -configuration, Debug, -sdk, iphonesimulator, clean, build]
[workspace] $ /Volumes/Overmind HD/Jenkins/checker-264/scan-build -k -v -v
-o /Volumes/Overmind HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports xcodebuild -target
ProjectExample -configuration Debug -sdk iphonesimulator clean build
scan-build: Emitting reports for this run to '/Volumes/Overmind
HD/Jenkins/Home/jobs/Project
Example-Develop/workspace/clangScanBuildReports/2012-05-23-1'.
(...)
scan-build:
[JIRA] (JENKINS-8317) Matrix jobs with custom workspaces should be able to share the root with no axis-specific subtree
[
https://issues.jenkins-ci.org/browse/JENKINS-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163147#comment-163147
]
Andy M commented on JENKINS-8317:
-
Any update on this? The aforementioned discussion about the pull request seems
unrelated?
Matrix jobs with custom workspaces should be able to share the root with no
axis-specific subtree
-
Key: JENKINS-8317
URL: https://issues.jenkins-ci.org/browse/JENKINS-8317
Project: Jenkins
Issue Type: Improvement
Components: core, matrix
Affects Versions: current
Reporter: mleinart
Assignee: mleinart
JENKINS-5077 created the ability to use custom workspaces in matrix jobs,
however the implementation keeps the creation of a subtree specific to the
axis and target (e.g. ${WORKSPACE}/axis1/a/axis2/b). This doesnt make sense
some (most?) of the time as you're then not actually in the custom workspace
you defined, but instead inside a subtree.
We need an option to disable this subtree creation so that all runs of a
matrix job can share the root of a custom workspace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13625) ERR_CONTENT_DECODING_FAILED returned on testResults and console output after Jenkins reload
[ https://issues.jenkins-ci.org/browse/JENKINS-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163148#comment-163148 ] SCM/JIRA link daemon commented on JENKINS-13625: Code changed in jenkins User: Kohsuke Kawaguchi Path: core/pom.xml core/src/main/java/hudson/security/HudsonAuthenticationEntryPoint.java core/src/main/java/jenkins/model/Jenkins.java war/src/main/webapp/WEB-INF/web.xml http://jenkins-ci.org/commit/jenkins/18963ee9af2b98ce94eda799069d9135f6031a0e Log: [FIXED JENKINS-13625] In the end, proper fix requires having a filter that tracks GZipOutputStream. Compare: https://github.com/jenkinsci/jenkins/compare/be1f8f9...18963ee ERR_CONTENT_DECODING_FAILED returned on testResults and console output after Jenkins reload --- Key: JENKINS-13625 URL: https://issues.jenkins-ci.org/browse/JENKINS-13625 Project: Jenkins Issue Type: Bug Components: core, matrix, swarm Affects Versions: current Reporter: Anders Nickelsen Assignee: Kohsuke Kawaguchi Priority: Critical We have matrix configuration job that has a 'slave' axis to distribute tests on Jenkins swarm slaves. When we 'reload configuration from disk' Jenkins all builds in the history of the matrix job return ERR_CONTENT_DECODING_FAILED (HTTP error 330) when we request console output for any slave on the axis. This also occurs when requesting testresults (we record jUnit test results as a part of the build). We had issues with Jenkins losing references to slave after reload, which were solved by https://issues.jenkins-ci.org/browse/JENKINS-8043, and I think this bug is related. When the error occurs the following stack trace is observed in Jenkins' log: 27-Apr-2012 08:26:50 winstone.Logger logInternal WARNING: Untrapped Error in Servlet javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.461.jar!/hudson/tasks/test/MatrixTestResult/index.jelly:42:60: j:forEach java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) 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.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
[JIRA] (JENKINS-13625) ERR_CONTENT_DECODING_FAILED returned on testResults and console output after Jenkins reload
[ https://issues.jenkins-ci.org/browse/JENKINS-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13625. Resolution: Fixed ERR_CONTENT_DECODING_FAILED returned on testResults and console output after Jenkins reload --- Key: JENKINS-13625 URL: https://issues.jenkins-ci.org/browse/JENKINS-13625 Project: Jenkins Issue Type: Bug Components: core, matrix, swarm Affects Versions: current Reporter: Anders Nickelsen Assignee: Kohsuke Kawaguchi Priority: Critical We have matrix configuration job that has a 'slave' axis to distribute tests on Jenkins swarm slaves. When we 'reload configuration from disk' Jenkins all builds in the history of the matrix job return ERR_CONTENT_DECODING_FAILED (HTTP error 330) when we request console output for any slave on the axis. This also occurs when requesting testresults (we record jUnit test results as a part of the build). We had issues with Jenkins losing references to slave after reload, which were solved by https://issues.jenkins-ci.org/browse/JENKINS-8043, and I think this bug is related. When the error occurs the following stack trace is observed in Jenkins' log: 27-Apr-2012 08:26:50 winstone.Logger logInternal WARNING: Untrapped Error in Servlet javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.461.jar!/hudson/tasks/test/MatrixTestResult/index.jelly:42:60: j:forEach java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) 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.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.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at
[JIRA] (JENKINS-13886) Settings in Configure System are reset when the server is reset
John Grattan created JENKINS-13886: -- Summary: Settings in Configure System are reset when the server is reset Key: JENKINS-13886 URL: https://issues.jenkins-ci.org/browse/JENKINS-13886 Project: Jenkins Issue Type: Bug Components: xcode Affects Versions: current Reporter: John Grattan The setting under Jenkins Manage Jenkins Configure System for Xcode Builder are being reset when the server is reset. I have been changing the xcodebuild executable path from the default - to use the same xcodebuild that is being used by Xcode (4.3). When ever the server is reset, the property is being changed back to the default: /usr/bin/xcodebuild, while other properties (such as E-mail Notification) retain their values. I am using: - Jenkins ver. 1.464 - Xcode integration 1.3.1 Currently I am just changing it back manually every time we do a server reset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13887) Ability to change the Bundle identifier (CFBundleIdentifier) for an xcode build
John Grattan created JENKINS-13887: -- Summary: Ability to change the Bundle identifier (CFBundleIdentifier) for an xcode build Key: JENKINS-13887 URL: https://issues.jenkins-ci.org/browse/JENKINS-13887 Project: Jenkins Issue Type: New Feature Components: xcode Reporter: John Grattan Priority: Minor Similar to the Technical Version Number (CFBundleVersion), it would be nice to have an option to change the Bundle identifier (CFBundleIdentifier). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13889) Cobertura plugin is not able to find code from python coverage
cangove created JENKINS-13889: - Summary: Cobertura plugin is not able to find code from python coverage Key: JENKINS-13889 URL: https://issues.jenkins-ci.org/browse/JENKINS-13889 Project: Jenkins Issue Type: Bug Components: cobertura Affects Versions: current Reporter: cangove Assignee: stephenconnolly Our repository has all src code under /src. So when running tests and coverage the coverage.xml file is generated in $WORKSPACE/src. In the job config I specify **/coverage.xml in the location. Th eCobertura plugin finds the coverage report but states: Source code is unavailable. Some possible reasons are: This is not the most recent build (to save on disk space, this plugin only keeps the most recent builds source code). Cobertura found the source code but did not provide enough information to locate the source code. Cobertura could not find the source code, so this plugin has no hope of finding it. I believe this is due to the fact that coverage.xml records the relative path to the files. As this file is in $WORKSPACE/src I would expect it to find the files in $WORKSPACE/src/relative path, but I susepct it's omitting the 'src' directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
