[JIRA] (JENKINS-58120) Fail to start on due to Pipeline: Step API dependency
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
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
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 java.lang.Thread.run(Thread.java:74
[JIRA] (JENKINS-21248) Add shallow update init for submodule
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
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
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
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)
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
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
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
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
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] [naginator] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name
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.
[JIRA] [naginator] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name
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: 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 Stack trace from jenkins.log:{code}Aug 18, 2014 10:21:34 AM hudson.model.RunMap retrieveWARNING: could not load /var/lib/jenkins/jobs/Deploy to dev and run QG/builds/2014-07-22_02-59-43java.io.IOException: Unable to read /var/lib/jenkins/jobs/Deploy to dev and run QG/builds/2014-07-22_02-59-43/build.xmlat hudson.XmlFile.unmarshal(XmlFile.java:167)at hudson.model.Run.reload(Run.java:323)at hudson.model.Run.(Run.java:311)at hudson.model.AbstractBuild.(AbstractBuild.java:177)at hudson.model.Build.(Build.java:103)at hudson.model.FreeStyleBuild.(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(CauseA
[JIRA] [walldisplay] (JENKINS-24300) Stackoverflow after IOException due to whitespace in Job name
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.(Run.java:311) at hudson.model.AbstractBuild.(AbstractBuild.java:177) at hudson.model.Build.(Build.java:103) at hudson.model.FreeStyleBuild.(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 jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:23