[JIRA] (JENKINS-58120) Fail to start on due to Pipeline: Step API dependency

2019-06-21 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-58120  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Fail to start on due to Pipeline: Step API dependency   
 

  
 
 
 
 

 
 Sure that might solve MY issue right now. The point is that this issue exists for everyone who upgrades mq-notifier-plugin, so this is a bug that needs to fixed in the plugin itself and not with a workaround.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200165.1561046097000.5431.1561117440129%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58120) Fail to start on due to Pipeline: Step API dependency

2019-06-21 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-58120  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Fail to start on due to Pipeline: Step API dependency   
 

  
 
 
 
 

 
 Thanks Thien Vu. I already have 2.14 installed, but because the new version of mq-notifier-plugin requires a newer version , it was installed an not compatible with the Jenkins version. My point of reporting this issue is to highlight that the update path is broken for older Jenkins versions. I guess the minimal required Jenkins version for mq-notifier-plugin can be updated to v2.121.1 to avoid this? At least a user can then not break Jenkins accidentally.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200165.1561046097000.5418.1561116240175%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58120) Fail to start on due to Pipeline: Step API dependency

2019-06-20 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58120  
 
 
  Fail to start on due to Pipeline: Step API dependency   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Tomas Westling  
 
 
Components: 
 mq-notifier-plugin  
 
 
Created: 
 2019-06-20 15:54  
 
 
Environment: 
 Jenkins ver. 2.89.3, mq-notifier-plugin 1.2.8  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Stefan Verhoeff  
 

  
 
 
 
 

 
 After upgrading the mq-notifier-plugin on 1.2.8 on Jenkins ver. 2.89.3, Jenkins failed to start up properly. It looks this Jenkins version breaks because of the "Pipeline: Step API" dependency which needs Jenkins version v2.121.1 or later. Startup error log: 

 
Jun 20, 2019 9:55:27 AM jenkins.InitReactorRunner$1 onTaskFailed
SEVERE: Failed Loading plugin Pipeline: Step API v2.20 (workflow-step-api)
java.io.IOException: Pipeline: Step API v2.20 failed to load.
 - You must update Jenkins from v2.89.3 to v2.121.1 or later to run this plugin.
at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:626)
at hudson.PluginManager$2$1$1.run(PluginManager.java:513)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1065)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 

[JIRA] (JENKINS-21248) Add shallow update init for submodule

2019-05-17 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-21248  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add shallow update init for submodule   
 

  
 
 
 
 

 
 Thanks for the details Mark Waite. I'm happy to help with testing this useful feature. How can I check what version of Git is used by the checkout() command? I assume it would be the same I get when I run git --version just above it. Is there a different Git binary used? Is the checkout actually happening on the Master and the sh() command on the agent? Is JGit involved? I'm confused here. As per your acceptance test, does this point at an issue with the version parsing or not? I've checked the code around where the warning Git client older than 1.8.4 doesn't support shallow submodule updates. This flag is ignored. is raised, the shallow clone arguments are never actually added to the Git command because of the failed version check, so I'm not getting errors from Git on this.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.152811.138908257.4434.1558111020528%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-21248) Add shallow update init for submodule

2019-05-17 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-21248  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add shallow update init for submodule   
 

  
 
 
 
 

 
 Tried this feature in beta git-4.0.0-beta9. But the plugin is refusing the allow the option: 

 
> git submodule init # timeout=10
[WARNING] Git client older than 1.8.4 doesn't support shallow submodule updates. This flag is ignored.
 

 However my Git version should support this, see output of sh 'git --version' in my pipeline script: 

 
+ git --version
git version 2.11.0
 

 Bug in the version detection?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.152811.138908257.3441.1558095601175%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-8618) would like to use one instance per build

2019-05-17 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff updated  JENKINS-8618  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Released in EC2 plugin Version 1.43  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-8618  
 
 
  would like to use one instance per build   
 

  
 
 
 
 

 
Change By: 
 Stefan Verhoeff  
 
 
Status: 
 Fixed but Unreleased Resolved  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.138729.1295990555000.620.1558081920665%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-57405) Stop/Disconnect on Idle Timeout feature not working after updating Node description template

2019-05-10 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57405  
 
 
  Stop/Disconnect on Idle Timeout feature not working after updating Node description template   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 FABRIZIO MANFREDI  
 
 
Components: 
 ec2-plugin  
 
 
Created: 
 2019-05-10 12:01  
 
 
Environment: 
 Jenkins ver. 2.150.1, EC2 plugin 1.43  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Stefan Verhoeff  
 

  
 
 
 
 

 
 Observed after upgrade from EC2 plugin 1.42 to 1.43. When changing the "Description" of an EC2 node template in the Jenkins config, the "Stop/Disconnect on Idle Timeout" feature does not work anymore for any nodes created before the change. The nodes stay stopped and new nodes are created instead of the old ones re-used. This also happens for any nodes that were created on Jenkins with an EC2 plugin version <1.43. Because in 1.43 the node names are updated with more information to the instance name (PR-334 [1]). This exception happens with that affect nodes, may be related: 

 
May 10, 2019 9:55:53 AM hudson.model.AbstractCIBase updateComputer
WARNING: Error updating node EC2 (Mobility RD EU-West-1) - android-m52xlarge-eu-west-1 (i-009cd08cab2a1f2b2), continuing
java.lang.NullPointerException
at hudson.plugins.ec2.EC2RetentionStrategy.internalCheck(EC2RetentionStrategy.java:140)
at hudson.plugins.ec2.EC2RetentionStrategy.check(EC2RetentionStrategy.java:92)
at hudson.plugins.ec2.EC2RetentionStrategy.check(EC2RetentionStrategy.java:50)
at hudson.slaves.SlaveComputer$4.run(SlaveComputer.java:843)
at hudson.model.Queue._withLock(Queue.java:1381)
at hudson.model.Queue.withLock(Queue.java:1258)

[JIRA] (JENKINS-53664) AWS Device Farm plugin affected by JEP-200 (regression)

2019-02-21 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-53664  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: AWS Device Farm plugin affected by JEP-200 (regression)   
 

  
 
 
 
 

 
 Yes this is a regression introduced due to a bad merge. Fixed in this PR: https://github.com/awslabs/aws-device-farm-jenkins-plugin/pull/90  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54187) EC2 Plugin deadlock leaving Jenkins unresponsive

2018-12-14 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-54187  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: EC2 Plugin deadlock leaving Jenkins unresponsive   
 

  
 
 
 
 

 
 Same issue again after accidentally upgrading to ec2-1.41 and Jenkins LTS 2.150.1.   Looks like this bug is a duplicate, linking: JENKINS-53858   Fix for JENKINS-53858 has been announced for 1.42 on the wiki: https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin#AmazonEC2Plugin-Version1.42(NotReleaseyet,2018)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-43171) Correct Pom for build-monitor-plugin

2018-05-22 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-43171  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Correct Pom for build-monitor-plugin   
 

  
 
 
 
 

 
 We have the same issue, using the build-monitor-plugin as dependency with Gradle. It's reported to the project's GitHub project: https://github.com/jan-molak/jenkins-build-monitor-plugin/issues/373  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-21747) Artifact archiving fails with java.lang.NoClassDefFoundError

2017-01-20 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff edited a comment on  JENKINS-21747  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Artifact archiving fails with java.lang.NoClassDefFoundError   
 

  
 
 
 
 

 
 Had the same issue  (Jenkins ver .  1.651.3).  For me also reconnecting the node fixed the issue. In my case the node had recently been restarted, so could be the file system with class files wasn't fully available yet.The question of course is if the root cause can be fixed to prevent this from happening at all.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-21747) Artifact archiving fails with java.lang.NoClassDefFoundError

2017-01-20 Thread stefan.verho...@here.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Verhoeff commented on  JENKINS-21747  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Artifact archiving fails with java.lang.NoClassDefFoundError   
 

  
 
 
 
 

 
 Had the same issue. For me also reconnecting the node fixed the issue. In my case the node had recently been restarted, so could be the file system with class files wasn't fully available yet. The question of course is if the root cause can be fixed to prevent this from happening at all.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] [walldisplay] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name

2014-08-18 Thread stefan.verho...@here.com (JIRA)














































Stefan Verhoeff
 created  JENKINS-24300


Stackoverflow after IOException due to whitespace in Job name















Issue Type:


Bug



Assignee:


Christian Pelster



Components:


walldisplay



Created:


18/Aug/14 10:23 AM



Description:


We experienced a crashing Jenkins server after Walldisplay started to report "timeout". Requests to the jobs view API URL at /view/view-name/api/json where timing out. CPU was a 100% and there were many hanging RequestHandler threads. In the logs we found IOExceptions on a job that contains whitespace which lead to a StackOverflowError.

After renaming the job to not contain whitespace the issue was solved.

Detailed Stacktrace from jenkins.log:

Aug 18, 2014 10:21:34 AM hudson.model.RunMap retrieve
WARNING: could not load /var/lib/jenkins/jobs/Deploy to dev and run QG/builds/2014-07-22_02-59-43
java.io.IOException: Unable to read /var/lib/jenkins/jobs/Deploy to dev and run QG/builds/2014-07-22_02
-59-43/build.xml
at hudson.XmlFile.unmarshal(XmlFile.java:167)
at hudson.model.Run.reload(Run.java:323)
at hudson.model.Run.init(Run.java:311)
at hudson.model.AbstractBuild.init(AbstractBuild.java:177)
at hudson.model.Build.init(Build.java:103)
at hudson.model.FreeStyleBuild.init(FreeStyleBuild.java:38)
at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.
java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at jenkins.model.lazy.LazyBuildMixIn.loadBuild(LazyBuildMixIn.java:155)
at jenkins.model.lazy.LazyBuildMixIn$1.create(LazyBuildMixIn.java:136)
at hudson.model.RunMap.retrieve(RunMap.java:218)
at hudson.model.RunMap.retrieve(RunMap.java:56)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671)
at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470)
at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547)
at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:235)
at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:956)
at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:144)
at hudson.model.Cause$UpstreamCause.onLoad(Cause.java:189)
at hudson.model.CauseAction.onLoad(CauseAction.java:124)
at hudson.model.Run.onLoad(Run.java:342)
at hudson.model.RunMap.retrieve(RunMap.java:219)
at hudson.model.RunMap.retrieve(RunMap.java:56)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671)
at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470)
at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547)
at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:235)
at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:956)
at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:144)
at hudson.model.Cause$UpstreamCause.onLoad(Cause.java:189)
at hudson.model.CauseAction.onLoad(CauseAction.java:124)
at hudson.model.Run.onLoad(Run.java:342)
at hudson.model.RunMap.retrieve(RunMap.java:219)
at hudson.model.RunMap.retrieve(RunMap.java:56)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671)
at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470)
at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547)
at 

[JIRA] [naginator] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name

2014-08-18 Thread stefan.verho...@here.com (JIRA)














































Stefan Verhoeff
 updated  JENKINS-24300


Stackoverflow after IOException due to whitespace in Job name
















Jenkins version is the latest: Jenkins ver. 1.575.

Browser is Chrome 36, although this looks like a backend issue.

I'm not convinced the issue is caused by Naginator. There are two exceptions in the trace I provided. I split them to make that more clear. The first is says "java.io.IOException: Unable to read" that seems to be caused by the directory named "Deploy to dev and run QG" contains whitespace.

The second exception is where Naginator shows up, but that could be just to retry the failed build. The exception that triggered it is "java.io.IOException: Failed to write firstBuild".

The NPE fix for Naginator is still a good one, but i'm not sure it fixed the root cause.





Change By:


Stefan Verhoeff
(18/Aug/14 4:43 PM)




Affects Version/s:


current





Description:


WeexperiencedacrashingJenkinsserverafterWalldisplaystartedtoreporttimeout.RequeststothejobsviewAPIURLat/view/view-name/api/jsonwheretimingout.CPUwasa100%andthereweremanyhangingRequestHandlerthreads.InthelogswefoundIOExceptionsonajobthatcontainswhitespacewhichleadtoaStackOverflowError.Afterrenamingthejobtonotcontainwhitespacetheissuewassolved.Detailed
Stacktrace
Stacktrace

[JIRA] [naginator] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name

2014-08-18 Thread stefan.verho...@here.com (JIRA)














































Stefan Verhoeff
 commented on  JENKINS-24300


Stackoverflow after IOException due to whitespace in Job name















The stack trace does look very similar to JENKINS-24161. It might have been a coincidence that renaming the job fixed the issue for us. That job did not have any problems for the past 4000 builds. We upgraded Jenkins a week ago.

I will update the ticket if this issue occurs again with the version 1.576.

Thanks 



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.