[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-61103 LinkageError on agent following RemotingSystemException(InterruptedException) Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/remoting/pull/ 372 379 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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.204615.1581800768000.18979.1588089180223%40Atlassian.JIRA.
[JIRA] (JENKINS-30680) Make Custom Tools compatible with Pipeline
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-30680 Re: Make Custom Tools compatible with Pipeline out of curiosity, what is wrong with just using it via current "tool" step support? Why do we need a custom step for this? Using a Custom Tool from a Pipeline (with "tool") kind of works; the tool gets installed, and you get back the path to its homedir. But: if the tool declares extra PATH entries (for instance for a "bin" sub-folder), you must know it, and set the PATH+BLAH accordingly in your "withEnv" wrapper arguments if the tool declares other extra environment variables, you must know it too, and explicitly define them in your Pipeline, again using "withEnv" So basically, you must be aware of some internal details of the Custom Tool definition, and replicate them in your Pipeline. (And that's just what I find annoying for my use cases, but I don't use all features of Custom Tools; I've never played with "versions", I don't know how they work in a Pipeline context.) Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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
[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-61103 Re: LinkageError on agent following RemotingSystemException(InterruptedException) Thanks Adam for the pointer to JDK bug 8051847, interesting reading. I didn't know about https://github.com/kohsuke/eiie-logger, that's pretty clever! Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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.204615.1581800768000.1139.1583539680140%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title
Thomas de Grenier de Latour updated an issue
Jenkins / JENKINS-43889
ssh-agent-plugin leaking some ssh-agent processes
Change By:
Thomas de Grenier de Latour
When a job with the {{SSHAgentBuildWrapper}} enabled fails very early (for instance during SCM checkout), an {{ssh-agent}} process is left behind. The issue is that the {{SSHAgentEnvironment}} is instantiated very early (from {{preCheckout}}), but its {{tearDown}} method will only be called if execution reaches {{BuildExecution.doRun}} (which comes after the SCM checkout phase in {{AbstractBuildExecution.run}}).Before {{ssh-agent-plugin 1.14}}, there was no {{ssh-agent}} process, so the issue with some {{SSHAgentEnvironment}} not being teared torn down was less visible (but probably there was already some other kind of less obvious resources leaks with {{AgentServer}} not being properly closed).This kind of issue with some {{Environment}} not being properly teared torn down can happen as soon as they are not instantiated from {{BuildWrapper.setUp}}, but from earlier phases (like {{BuildWrapper.preCheckout}} or {{RunListener.setUpEnvironment}}). As such, maybe that's something that should be fixed in core (maybe in {{AbstractBuildExecution.run}}) rather than specifically in the {{ssh-agent-plugin}}, I don't know...I've written and attached a "generic workaround" {{RunListener}}, which tries to detect this situation from {{onComplete}}, and call {{tearDown}} for all {{Environment}} if it has not been done already. It's not something I propose for inclusion, but rather some code to exhibit the issue. If an ssh-agent specific fix is desirable, then a similar approach might be an option (but targeting {{SSHAgentEnvironment}} only).
Add Comment
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-43889 ssh-agent-plugin leaking some ssh-agent processes Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/jenkins/pull/4517 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.4838.1582412700460%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour assigned an issue to Thomas de Grenier de Latour Jenkins / JENKINS-43889 ssh-agent-plugin leaking some ssh-agent processes Change By: Thomas de Grenier de Latour Assignee: Thomas de Grenier de Latour Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.4839.1582412700488%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour started work on JENKINS-43889 Change By: Thomas de Grenier de Latour Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.4842.1582412700562%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-43889 Re: ssh-agent-plugin leaking some ssh-agent processes PR submitted: https://github.com/jenkinsci/jenkins/pull/4517 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.4835.1582412640206%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-43889 Re: ssh-agent-plugin leaking some ssh-agent processes Revisiting this old issue again, I realize that SimpleBuildWrapper exposes a variation of what's done in the SSHAgentBuildWrapper, allowing to setup an Environment before checkout: SimpleBuildWrapper#runPreCheckout If such a SimpleWrapperWrapper provides a Disposer and is run as part of an AbstractBuild which fails early (in SCM checkout), then the disposer won't be called. This flaw is again not documented (just like Environment#tearDown says nothing about not always being called on build failure), and makes me lean toward the "it's a core bug" interpretation of this issue. I will submit a PR with a test case (using SimpleBuildWrapper), and a possible fix. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.4800.1582408560287%40Atlassian.JIRA.
[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-61103 Re: LinkageError on agent following RemotingSystemException(InterruptedException) For information, another occurrence of this issue we've had in production a few days ago (not involving the Maven plugin): user launch a job, and then cancel it a few seconds later (edited Apache logs): IP.IP.IP.IP - [17/Feb/2020:16:17:24 +0100] "POST /jenkins/view/VIEW_NAME/job/JOB_NAME/build?delay=0sec HTTP/1.1" 201 241 "http://SOMETHING/jenkins/view/VIEW_NAME/job/JOB_NAME/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0" IP.IP.IP.IP - [17/Feb/2020:16:17:32 +0100] "POST /jenkins/view/VIEW_NAME/job/JOB_NAME/1/stop HTTP/1.1" 302 267 "http://SOMETHING/jenkins/view/VIEW_NAME/job/JOB_NAME/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0" slave.log at the time of interruption (it's similar to one of my previous examples, in RemoteClassLoader#findResource() / RemoteClassLoader.java:426): Feb 17, 2020 4:17:32 PM hudson.remoting.UserRequest perform WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask@8a955ea java.lang.ExceptionInInitializerError at hudson.security.PermissionGroup.(PermissionGroup.java:44) at hudson.security.PermissionGroup.(PermissionGroup.java:64) at hudson.model.Computer.(Computer.java:1761) at hudson.util.ProcessTree.get(ProcessTree.java:414) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1103) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1094) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:748) Caused by: hudson.remoting.RemotingSystemException: java.lang.InterruptedException at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:299) at com.sun.proxy.$Proxy5.getResource2(Unknown Source) at hudson.remoting.RemoteClassLoader.findResource(RemoteClassLoader.java:426) at java.lang.ClassLoader.getResource(ClassLoader.java:1096) at java.lang.Class.getResource(Class.java:2267) at org.jvnet.localizer.ResourceProvider$1.getResource(ResourceProvider.java:53) at org.jvnet.localizer.ResourceProvider.findResource(ResourceProvider.java:45) at org.jvnet.localizer.ResourceBundleHolder.get(ResourceBundleHolder.java:107) at
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Change By: Thomas de Grenier de Latour Status: Resolved Closed Assignee: Thomas de Grenier de Latour Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204298.1580317923000.1920.1582064520087%40Atlassian.JIRA.
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Change By: Thomas de Grenier de Latour Status: Resolved Closed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202346.1570194412000.1919.1582064400071%40Atlassian.JIRA.
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour updated JENKINS-59656 Fixed some time ago, closing. Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Change By: Thomas de Grenier de Latour Status: Fixed but Unreleased Resolved Released As: 2.209 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour assigned an issue to Thomas de Grenier de Latour Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Change By: Thomas de Grenier de Latour Assignee: Thomas de Grenier de Latour Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202346.1570194412000.1917.1582064280060%40Atlassian.JIRA.
[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title
Thomas de Grenier de Latour updated an issue
Jenkins / JENKINS-61103
LinkageError on agent following RemotingSystemException(InterruptedException)
whoops, wrong issue link, fixed
Change By:
Thomas de Grenier de Latour
I know this sound like a duplicate of some previously reported bugs, but I'm opening this new issue to have a single one I can refer to in a PR I'm about to open.I'm trying to improve resilience of the agent's {{RemoteClassLoader}} when it receives a {{RemotingSystemException}} caused by an {{InterruptedException}}.The overall issue is that the class loader can't really recover after an exception has been raised while some classes were being loaded / initialized; later attempts at using a class that failed being loaded/initialized will raise a {{LinkageError}}. This is not something new, see JENKINS-36991 / [PR #94|https://github.com/jenkinsci/remoting/pull/94]. This one got fixed by adding some try/catch/retry logic to the affected part of the {{RemoteClassLoader#findClass}} code. This way, the interruption can be deferred until after the class has been successfully loaded.But there are other parts of the {{RemoteClassLoader}} code which are not protected yet, despite being on the critical path of classes loading/initialization.See for instance JENKINS- 56767 51854 : the exception occurs in a call to {{RemoteClassLoader#getResource}} made during initialization of some Subversion plugin classes, and from there the plugin can't be used on this agent anymore.I've reproduced something similar with the Maven plugin, simply by interrupting (from the GUI) a Maven job while it was starting on a freshly started agent. - error (slave log) when this first Maven job execution gets interrupted:{code:java}Feb 10, 2020 5:51:39 PM hudson.remoting.UserRequest performWARNING: LinkageError while performing UserRequest:hudson.maven.MavenModuleSetBuild$PomParser@38569db8java.lang.ExceptionInInitializerError at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1276) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1126) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3071) at hudson.remoting.UserRequest.perform(UserRequest.java:211) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at
[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-61103 LinkageError on agent following RemotingSystemException(InterruptedException) Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/remoting/pull/372 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204615.1581800768000.335.1581803220245%40Atlassian.JIRA.
[JIRA] (JENKINS-61103) LinkageError on agent following RemotingSystemException(InterruptedException)
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-61103 LinkageError on agent following RemotingSystemException(InterruptedException) Issue Type: Bug Assignee: Jeff Thompson Components: remoting Created: 2020-02-15 21:06 Environment: Jenkins 2.204.2 (remoting 3.36.1) Linux OpenJDK 1.8.0_242 Priority: Major Reporter: Thomas de Grenier de Latour I know this sound like a duplicate of some previously reported bugs, but I'm opening this new issue to have a single one I can refer to in a PR I'm about to open. I'm trying to improve resilience of the agent's RemoteClassLoader when it receives a RemotingSystemException caused by an InterruptedException. The overall issue is that the class loader can't really recover after an exception has been raised while some classes were being loaded / initialized; later attempts at using a class that failed being loaded/initialized will raise a LinkageError. This is not something new, see JENKINS-36991 / PR #94. This one got fixed by adding some try/catch/retry logic to the affected part of the RemoteClassLoader#findClass code. This way, the interruption can be deferred until after the class has been successfully loaded. But there are other parts of the RemoteClassLoader code which are not protected yet, despite being on the critical path of classes loading/initialization. See for instance JENKINS-56767: the exception occurs in a call to RemoteClassLoader#getResource made during initialization of some Subversion plugin classes, and from there the plugin can't be used on this agent anymore. I've reproduced something similar with the Maven plugin, simply by interrupting (from the GUI) a Maven job while it was starting on a freshly started agent.
[JIRA] (JENKINS-47058) HTTP error 414 when editing a Batch/Shell tool installer
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Closing my old resolved issues... Jenkins / JENKINS-47058 HTTP error 414 when editing a Batch/Shell tool installer Change By: Thomas de Grenier de Latour Status: Resolved Closed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.185448.1506091348000.6368.1581409680083%40Atlassian.JIRA.
[JIRA] (JENKINS-30197) Migration from Subversion 1.x to 2.5.1+ can fail (ClassCastException on SCM)
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Closing my old resolved issues... Jenkins / JENKINS-30197 Migration from Subversion 1.x to 2.5.1+ can fail (ClassCastException on SCM) Change By: Thomas de Grenier de Latour Status: Resolved Closed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.164782.1440764735000.6363.1581409621620%40Atlassian.JIRA.
[JIRA] (JENKINS-30934) Changing crontab settings blocks "configSubmit" for 3x60 seconds
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Closing my old resolved issues... Jenkins / JENKINS-30934 Changing crontab settings blocks "configSubmit" for 3x60 seconds Change By: Thomas de Grenier de Latour Status: Resolved Closed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.165550.1444770688000.6365.1581409621697%40Atlassian.JIRA.
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour updated JENKINS-60907 Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Change By: Thomas de Grenier de Latour Status: Fixed but Unreleased Resolved Released As: https://jenkins.io/changelog/#v2.220 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204298.1580317923000.5231.1581323280216%40Atlassian.JIRA.
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Tagging as a LTS candidate (for 2.204.3), to be considered after it is released in the next weekly. It's not a critical fix, but on the other hand the change is pretty simple, can hardly have any undesirable side effects, and is useful in some use cases. Change By: Thomas de Grenier de Latour Labels: lts-candidate performance Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour updated JENKINS-60907 PR #4459 is now merged Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Change By: Thomas de Grenier de Latour Status: Open Fixed but Unreleased Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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
[JIRA] (JENKINS-60960) Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream)
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-60960 Re: Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream) Actually, I've found a fix/workaround which could be implemented in durable-task plugin: https://github.com/jenkinsci/durable-task-plugin/pull/120 Apparently, closing the unused streams is enough to release their remote counterpart (more details in the PR). Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204420.1580815533000.2253.1580986740309%40Atlassian.JIRA.
[JIRA] (JENKINS-60960) Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream)
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-60960 Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream) Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/durable-task-plugin/pull/120 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204420.1580815533000.2251.1580986320211%40Atlassian.JIRA.
[JIRA] (JENKINS-60960) Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream)
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-60960 Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream) Issue Type: Bug Assignee: Unassigned Attachments: modified-smokeTest-failed-output.txt Components: core, durable-task-plugin Created: 2020-02-04 11:25 Environment: Jenkins 2.204.2 durable-task 1.33 Linux, OpenJDK 8 Priority: Major Reporter: Thomas de Grenier de Latour I came across some OOM errors on some agents which were online for 2-3 weeks. Heap dumps showed thousands of of java.lang.UNIXProcess$ProcessPipeInputStream objects retained by the remoting ExportTable. There was no zombie process on the agent VM, and all these ProcessPipeInputStream were linked to the ProcessBuilder.NullInputStream.INSTANCE, which also suggests they were for processes which had already exited, at least from what I understand of this code: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java#l525 Because these input streams are also BufferedInputStream, each of them retains an 8KB byte array, thus a significant amount of memory when you have thousands of them. In the dumps ExportTable$CreatedAt of these entries, the allocationTrace was, unfortunately, not super helpful to identify the root cause (but maybe it's just me looking at stuff I don't know):
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-60907 Re: Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true With buffered streams (PR #4459), my test case with traffic compression disabled now completes in ~30 seconds (vs. ~50 seconds with compression). Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204298.1580317923000.8464.1580332020049%40Atlassian.JIRA.
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/jenkins/pull/4459 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.204298.1580317923000.8463.1580331840073%40Atlassian.JIRA.
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title
Thomas de Grenier de Latour updated an issue
Jenkins / JENKINS-60907
Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Change By:
Thomas de Grenier de Latour
With the new {{jenkins.model.StandardArtifactManager.disableTrafficCompression}} property (JENKINS-26008 / [PR #4205|https://github.com/jenkinsci/jenkins/pull/4205]), I was expecting improved performances when archiving artifacts from slaves to master. Especially when there is no room for further compression (when the artifact is already a compressed archive). But my first tests with 2.204.1 and this option are disappointing. On my test setup:- with traffic compression (default setting), archiving a ~200 MB .tar.gz file consistently takes ~50 seconds (which is really not great already)- without traffic compression (the new option), it now takes ~240 seconds!I suspect this is because {{FilePath.TarCompression.NONE}} lacks a layer of buffering input/output streams, which is there in {{FilePath.TarCompression.GZIP}}:[FilePath.java#L758|https://github.com/jenkinsci/jenkins/blob/jenkins-2.204.1/core/src/main/java/hudson/FilePath.java#L758] - {{GZIPInputStream}} is a buffering {{InputStream}} (here with buffer size set to 8K) - {{GZIPOutputStream}} is a buffering {{OutputStream}} (with a default buffer size of 512), and here there is also an addition additionnal {{BufferedOutputStream}} involved (with its default buffer size of 8K)I will submit a PR for {{FilePath.TarCompression.NONE}} to add the missing buffering layer, such so that the difference with {{GZIP}} will really only be only about compression.
Add Comment
[JIRA] (JENKINS-60907) Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-60907 Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true Issue Type: Bug Assignee: Unassigned Components: core Created: 2020-01-29 17:12 Environment: Jenkins 2.204.1 Linux (Ubuntu 18.04) OpenJDK 8u242 Priority: Minor Reporter: Thomas de Grenier de Latour With the new jenkins.model.StandardArtifactManager.disableTrafficCompression property (JENKINS-26008 / PR #4205), I was expecting improved performances when archiving artifacts from slaves to master. Especially when there is no room for further compression (when the artifact is already a compressed archive). But my first tests with 2.204.1 and this option are disappointing. On my test setup: with traffic compression (default setting), archiving a ~200 MB .tar.gz file consistently takes ~50 seconds (which is really not great already) without traffic compression (the new option), it now takes ~240 seconds! I suspect this is because FilePath.TarCompression.NONE lacks a layer of buffering input/output streams, which is there in FilePath.TarCompression.GZIP: FilePath.java#L758 GZIPInputStream is a buffering InputStream (here with buffer size set to 8K) GZIPOutputStream is a buffering OutputStream (with a default buffer size of 512), and here there is also an addition
[JIRA] (JENKINS-60522) NullPointerException despite report being in the directory
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-60522 Re: NullPointerException despite report being in the directory The problem here is that you're pointing an HTML report instead of an XML report: [DependencyCheck] Unable to parse /var/jenkins_home/testws/results/dependency-check-report.html Since the .html is all you have in your results directory, I guess you're specifying the --format HTML parameter. Try adding --format XML too, you'll get both output files, and then point your publisher to dependency-check-report.xml (and you can use the Publish HTML report plugin to publish the HTML too if you want). The NPE simply looks like an unfortunate side effect of this error. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.203619.1576656673000.7626.1580248620124%40Atlassian.JIRA.
[JIRA] (JENKINS-59869) OWASP Dependency-Check Plugin v5.2.2 declarative pipeline java not recognized
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-59869 Re: OWASP Dependency-Check Plugin v5.2.2 declarative pipeline java not recognized Not sure. The environment is being passed to the launcher which executes the CLI. Unfortunately, the environment which is passed is not the right one (in a Pipeline, it won't include contributions from build wrappers, or the environment directive of a Declarative Pipeline, etc.). See JENKINS-29144, one has to implement Step rather than SimpleBuildStep to get access to the contextual environment in a Pipeline. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202611.1571668367000.7622.1580247720276%40Atlassian.JIRA.
[JIRA] (JENKINS-60434) "Prepare for shutdown" should continue executing already running pipelines to completion
Title: Message Title
Thomas de Grenier de Latour commented on JENKINS-60434
Re: "Prepare for shutdown" should continue executing already running pipelines to completion
In case it can be useful to anyone, here is the "planned upgrade" process we have for Jenkins in my company. It relies on a custom quiet-mode implementation we've implemented in an internal plugin, which basically allows already running builds to terminate (including Pipelines), but forbids starting execution of new builds (expect if they are necessary for termination of the already running builds). The overall process is automated (we have many Jenkins instances), and it goes like this:
activate the custom quiet-down mode (forbid starting new builds)
poll Jenkins until it's idle, for up to X minutes, and then do the upgrade (including an actual restart)
on time-out of this polling, cancel the planned upgrade (cancel the custom quiet-mode), and retry it all later (sometimes we have to find arrangements with users, so that they don't launch their freaking 18 hours tests suite on the day we are planning to do an upgrade)
We don't have plans/time to publish and maintain this as a community plugin, but if someone wants to do something similar, I will dump the code below, feel free to reuse what you want. Note that we would probably never had written this code if we had not been bitten many times by JENKINS-34256. A few years ago, we were simply using the standard Jenkins quiet-mode, but then stuck Pipelines (when the upgrade was cancelled) really became an issue... Now that JENKINS-34256 is fixed, I don't know, we might consider going back to this standard solution. But I think our users prefer having their Pipelines finished before the upgrade, rather than paused/resumed (mainly because the "resume" part is not always smooth: some plugins upgrades might break compatibility of the serialized data, etc.). Anyway, this is the "interesting" part of the code, the QuietDownQueueTaskDispatcher, which filters which new Queue.Item can actually be started when in (custom) quiet-mode.
@Extension
public class QuietDownQueueTaskDispatcher extends QueueTaskDispatcher {
@Inject
QuietDownStateManager quietDownStateManager;
// key: upstreamProject+upstreamBuild from an UpstreamCause
// value: true if children builds should be allowed to run
private ConcurrentHashMap knownUpstreamCauses = new ConcurrentHashMap<>();
// used to decide when cache should be flushed
private AtomicLong quietDownTimestamp = new AtomicLong(0l);
@Override
public @CheckForNull CauseOfBlockage canRun(Queue.Item item) {
QuietDownState currentState = quietDownStateManager.getState();
if (!currentState.isDown()) {
return null;
}
// flush cache if quietDown state has changed
if (quietDownTimestamp.getAndSet(currentState.since()) != currentState.since()) {
knownUpstreamCauses.clear();
}
Queue.Task task = item.task;
// always allow some kind of tasks
if (task instanceof NonBlockingTask || task instanceof ContinuedTask) {
return null;
}
// allow build task because of its upstream cause
if (hasAllowingCause(item.getCauses())) {
return null;
}
// not allowed, let's
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour updated JENKINS-59656 Fixed via PR #4264, should be released in 2.209. Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Change By: Thomas de Grenier de Latour Status: Open Fixed but Unreleased Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title
Thomas de Grenier de Latour edited a comment on JENKINS-43889
Re: ssh-agent-plugin leaking some ssh-agent processes
I had kind of forgotten about this issue, because we've been using a {{RunListener}} to work around it, similar to the one I had attached already, but if anyone is interested, the report is still relevant (just checked with ssh-agent plugin code from master, and Jenkins 2.190.2).Here is a failing test case one can try, to be added in {{SSHAgentBuildWrapperTest}}:{code:java}@Issue("JENKINS-43889")@Testpublic void sshAgentStoppedOnEarlyBuildFailure() throws Exception {List credentialIds = new ArrayList();credentialIds.add(CREDENTIAL_ID);SSHUserPrivateKey key = new BasicSSHUserPrivateKey(CredentialsScope.GLOBAL, credentialIds.get(0), "cloudbees",new BasicSSHUserPrivateKey.DirectEntryPrivateKeySource(getPrivateKey()), "cloudbees", "test");SystemCredentialsProvider.getInstance().getCredentials().add(key);SystemCredentialsProvider.getInstance().save();FreeStyleProject job = r.createFreeStyleProject("I_will_die_during_SCM_checkout");job.setAssignedNode(r.createSlave());SSHAgentBuildWrapper sshAgent = new SSHAgentBuildWrapper(credentialIds, false);job.getBuildWrappersList().add(sshAgent);// make sure this job fails during SCM checkoutjob.setScm(new FailingSCM());Future build = job.scheduleBuild2(0);r.assertBuildStatus(Result.FAILURE, build);r.assertLogContains(Messages.SSHAgentBuildWrapper_Started(), build.get());r.assertLogContains(Messages.SSHAgentBuildWrapper_Stopped(), build.get());}static class FailingSCM extends SCM {@Overridepublic ChangeLogParser createChangeLogParser() {return null;}// default implementation of checkout(...) method will fail, that's what we want}{code}(you will then have come some `ssh-agent` processes to kill after running this test)I'm still not sure where this should get fixed: - either in core, by moving the {{Environment.tearDown}} calls up from {{BuildExecution.doRun}} to {{AbstractBuildExecution.run}} - or in the ssh-agent plugin itself, if what it does (ie., adding an {{Environment}} to the build from its {{BuildWrapper.preCheckout}} implementation, rather than from {{BuildWrapper.setUp}}, so that its already set up during SCM checkout) is really bad/unsupported
Add Comment
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-43889 Re: ssh-agent-plugin leaking some ssh-agent processes Added "core" to Component/s, because I really don't know who's wrong here (the plugin code or Jenkins code). Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.12116.1573506660181%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-43889 ssh-agent-plugin leaking some ssh-agent processes Change By: Thomas de Grenier de Latour Component/s: core Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.12113.1573506480501%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-43889 ssh-agent-plugin leaking some ssh-agent processes Change By: Thomas de Grenier de Latour Environment: Jenkins 2.32.3 , 2.190.2 ssh-agent-plugin 1.15 , 1.17 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.181417.1493285867000.12112.1573506480471%40Atlassian.JIRA.
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title
Thomas de Grenier de Latour edited a comment on JENKINS-43889
Re: ssh-agent-plugin leaking some ssh-agent processes
I had kind of forgotten about this issue, because we've been using a {{RunListener}} to work around it, similar to the one I had attached already, but if anyone is interested, the report is still relevant (just checked with ssh-agent plugin code from master, and Jenkins 2.190.2).Here is a failing test case one can try, to be added in {{SSHAgentBuildWrapperTest}}:{code:java}@Issue("JENKINS-43889")@Testpublic void sshAgentStoppedOnEarlyBuildFailure() throws Exception {List credentialIds = new ArrayList();credentialIds.add(CREDENTIAL_ID);SSHUserPrivateKey key = new BasicSSHUserPrivateKey(CredentialsScope.GLOBAL, credentialIds.get(0), "cloudbees",new BasicSSHUserPrivateKey.DirectEntryPrivateKeySource(getPrivateKey()), "cloudbees", "test");SystemCredentialsProvider.getInstance().getCredentials().add(key);SystemCredentialsProvider.getInstance().save();FreeStyleProject job = r.createFreeStyleProject("I_will_die_during_SCM_checkout");job.setAssignedNode(r.createSlave());SSHAgentBuildWrapper sshAgent = new SSHAgentBuildWrapper(credentialIds, false);job.getBuildWrappersList().add(sshAgent);// make sure this job fails during SCM checkoutjob.setScm(new FailingSCM());Future build = job.scheduleBuild2(0);r.assertBuildStatus(Result.FAILURE, build);r.assertLogContains(Messages.SSHAgentBuildWrapper_Started(), build.get());r.assertLogContains(Messages.SSHAgentBuildWrapper_Stopped(), build.get());}static class FailingSCM extends SCM {@Overridepublic ChangeLogParser createChangeLogParser() {return null;}// default implementation of checkout(...) method will fail, that's what we want} {code} (you will then have come `ssh-agent` processes to kill after running this test) {code} I'm still not sure where this should get fixed:- either in core, by moving the {{Environment.tearDown}} calls up from {{BuildExecution.doRun}} to {{AbstractBuildExecution.run}}- or in the ssh-agent plugin itself, if what it does (ie., adding an {{Environment}} to the build from its {{BuildWrapper.preCheckout}} implementation, rather than from {{BuildWrapper.setUp}}, so that its already set up during SCM checkout) is really bad/unsupported
Add Comment
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-43889 Re: ssh-agent-plugin leaking some ssh-agent processes To be extra clear in my explanations, here is how the ssh-agent gets launched, starting from AbstractBuild.AbstractBuildExecution#run: AbstractBuild.AbstractBuildExecution#run(...) - AbstractBuild.java#L498 SCMCheckoutStrategy#preCheckout(...) - SCMCheckoutStrategy.java#L76 SSHAgentBuildWrapper#preCheckout(...) - SSHAgentBuildWrapper.java#L228 SSHAgentBuildWrapper#createSSHAgentEnvironment(...) - SSHAgentBuildWrapper.java#L248 SSHAgentBuildWrapper.SSHAgentEnvironment#SSHAgentEnvironment(...) - SSHAgentBuildWrapper.java#L363 And here is how it gets stopped (when it does), again starting from AbstractBuild.AbstractBuildExecution#run (a few lines below): AbstractBuild.AbstractBuildExecution#run(...) - AbstractBuild.java#L504 Build#doRun(...) - Build.java#L174 SSHAgentBuildWrapper.SSHAgentEnvironment#tearDown(...) - SSHAgentBuildWrapper.java#L417 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes
Title: Message Title
Thomas de Grenier de Latour commented on JENKINS-43889
Re: ssh-agent-plugin leaking some ssh-agent processes
I had kind of forgotten about this issue, because we've been using a RunListener to work around it, similar to the one I had attached already, but if anyone is interested, the report is still relevant (just checked with ssh-agent plugin code from master, and Jenkins 2.190.2). Here is a failing test case one can try, to be added in SSHAgentBuildWrapperTest:
@Issue("JENKINS-43889")
@Test
public void sshAgentStoppedOnEarlyBuildFailure() throws Exception {
List credentialIds = new ArrayList();
credentialIds.add(CREDENTIAL_ID);
SSHUserPrivateKey key = new BasicSSHUserPrivateKey(CredentialsScope.GLOBAL, credentialIds.get(0), "cloudbees",
new BasicSSHUserPrivateKey.DirectEntryPrivateKeySource(getPrivateKey()), "cloudbees", "test");
SystemCredentialsProvider.getInstance().getCredentials().add(key);
SystemCredentialsProvider.getInstance().save();
FreeStyleProject job = r.createFreeStyleProject("I_will_die_during_SCM_checkout");
job.setAssignedNode(r.createSlave());
SSHAgentBuildWrapper sshAgent = new SSHAgentBuildWrapper(credentialIds, false);
job.getBuildWrappersList().add(sshAgent);
// make sure this job fails during SCM checkout
job.setScm(new FailingSCM());
Futureextends FreeStyleBuild> build = job.scheduleBuild2(0);
r.assertBuildStatus(Result.FAILURE, build);
r.assertLogContains(Messages.SSHAgentBuildWrapper_Started(), build.get());
r.assertLogContains(Messages.SSHAgentBuildWrapper_Stopped(), build.get());
}
static class FailingSCM extends SCM {
@Override
public ChangeLogParser createChangeLogParser() {
return null;
}
// default implementation of checkout(...) method will fail, that's what we want
}
(you will then have come `ssh-agent` processes to kill after running this test)
I'm still not sure where this should get fixed:
either in core, by moving the Environment.tearDown calls up from BuildExecution.doRun to AbstractBuildExecution.run
or in the ssh-agent plugin itself, if what it does (ie., adding an Environment to the build from its BuildWrapper.preCheckout implementation, rather than from BuildWrapper.setUp, so that its already set up during SCM checkout) is really bad/unsupported
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-59656 Re: executors widget makes it easy to interrupt the wrong build I will submit a WIP PR with a proposed change to avoid this issue... The PR is not WIP anymore, just needs more review. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202346.1570194412000.11094.1573205700166%40Atlassian.JIRA.
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-59656 Re: executors widget makes it easy to interrupt the wrong build Steps to reproduce when running with only the Jenkins war (as in jenkins-dev:run): create a test freestyle job with a "sleep 10" shell step go back to Jenkins main page, and launch the job twice; default job config will make it run one build at a time as soon as build #1 appears running in the executors view, click the stop button; you get the dialog to confirm interruption of build #1 count to 10 slowly, and click OK check that build #1 is in success, and it's build #2 which got interrupted That's basically how I've tested my proposed changes so far... Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202346.1570194412000.1080.1570197180112%40Atlassian.JIRA.
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Change By: Thomas de Grenier de Latour URL: https://github.com/jenkinsci/jenkins/pull/4264 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.202346.1570194412000.1074.1570195620067%40Atlassian.JIRA.
[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-59656 executors widget makes it easy to interrupt the wrong build Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-10-04 13:06 Environment: found in Jenkins 2.176.3, reproduced in Jenkins 2.198 Priority: Minor Reporter: Thomas de Grenier de Latour In Jenkins classical UI, users can interrupt builds using the stop button (little red cross) attached to each busy executor. Clicking this button displays a confirmation dialog (with the full display name of the build about to be interrupted, which is good). Then, on confirmation, a stop request is POSTed to the executor URL, which is something like this: /jenkins/computer/SOME_NAME/executors/NUMBER/stop or that: /jenkins/computer/(master)/oneOffExecutors/NUMBER/stop (and I guess it's not the only options, but you get the idea: the target is an executor, not a specific running task) Between the initial click on the cancel button and the stop request actually reaching the server, many things can happen (especially if the user hesitated on the confirmation dialog). The target executor identified by its name+number can now be executing something completely different from the build that the user was intending to interrupt. This is not a theoretical issue: I've came across this yesterday while doing the post-mortem analysis of an unintentionally interrupted deployment Pipeline I will submit a WIP PR with a proposed change to avoid this issue...
[JIRA] (JENKINS-58296) Projects are triggered twice when using File Parameter and Firefox 67
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-58296 Re: Projects are triggered twice when using File Parameter and Firefox 67 I'm starting to doubt this change was really necessary (my understanding of JENKINS-53462 was that form submission without this patch should have broke in recent FF versions) Latest comments from https://bugzilla.mozilla.org/show_bug.cgi?id=1370630 suggest that this "upcoming" change to FF which was requiring acc4eec688a (#3761 / JENKINS-53462) has actually been backed out during the 69 beta cycle (it was also never merged in FF 68, and there is no mention of a merge in FF 70 in this bugzilla issue). This explains that, I guess... The only remaining mystery (for me, but I might also be misinterpreting everything) is that Jenkins 2.176.3 actually works fine (including when submitting forms with file inputs) in FF 66. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.200361.1562053852000.9285.1569966420305%40Atlassian.JIRA.
[JIRA] (JENKINS-58296) Projects are triggered twice when using File Parameter and Firefox 67
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-58296 Re: Projects are triggered twice when using File Parameter and Firefox 67 I've not tried 2.190.1 yet, but I can definitely reproduce this double-submit issue with Firefox 68.1.0esr and 70.0b10, and Jenkins 2.176.3, as soon as there are file parameters for a job. I don't think "Parameterized Trigger Plugin" has anything to do with this issue, it can be reproduced while running Jenkins from sources with "mvn org.jenkins-ci.tools:maven-jenkins-dev-plugin:run", which doesn't include this plugin. And I definitely can't reproduce if using Firefox 66, the latest version available on Ubuntu Trusty (I've not tried 67). Also, I see the same issue in the plugins manager (running from Jenkins sources on the 2.176.3 tag): go to /jenkins/pluginManager/advanced select some random file to upload (don't bother picking a real .hpi if you don't actually want to install a plugin) submit (with Firefox dev tools enabled on network monitor) notice that there are 2 identical POST requests sent for /jenkins/pluginManager/uploadPlugin (and in case you actually upload a .hpi plugin, you'll see in Jenkins log that there are two attempts at loading it, with the later in failure) Of course I can't say for sure that the "file parameters" bug on jobs and the ".hpi plugin upload" bug are indeed the same bug, but it sounds really very similar. Oh, and I've tried reverting acc4eec688a (from #3761 / JENKINS-53462), again on 2.176.3 sources: it fixes the issue both for running jobs with file parameters, and for uploading a file to the plugins manager. Actually, with this commit reverted, it seems that everything works fine in these two forms, both in FF 66 and 70. And running a job with no file parameter (only a string parameter) works fine too, so I'm starting to doubt this change was really necessary (my understanding of JENKINS-53462 was that form submission without this patch should have broke in recent FF versions). Add Comment
[JIRA] (JENKINS-50600) Infinite loop with crontab (day-of-month out of range for previous month)
Title: Message Title Thomas de Grenier de Latour closed an issue as Fixed Closing this issue, it has been dealt with as SECURITY-790, and fixed in 2.121.3 / 2.138. Jenkins / JENKINS-50600 Infinite loop with crontab (day-of-month out of range for previous month) Change By: Thomas de Grenier de Latour Status: Open Closed Resolution: Fixed Released As: https://jenkins.io/security/advisory/2018-08-15/#SECURITY-790 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
[JIRA] (JENKINS-53466) ownership-plugin loading failure on startup
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-53466 Re: ownership-plugin loading failure on startup Some more info, not sure they're much useful: this issue also happens with come older LTS (2.107.3) and latest weekly (2.141) this issue also happens with -Djenkins.InitReactorRunner.concurrency=1 when booting Jenkins with -Djenkins.model.Jenkins.logStartupPerformance=true, I can see the matrix-auth plugin (which provides the "missing" descriptor) is correctly loaded before the ownership plugin when booting Jenkins without the ownership plugin, but with the "broken" ownership.xml file (ownership-KO.xml) already in place, and then dynamically adding the ownership plugin (0.12.1) via the update center, it loads just fine (and its global configuration is as expected, as in ownership-config-KO.png): Sep 10, 2018 3:03:20 PM hudson.model.UpdateCenter$DownloadJob run INFO: Starting the installation of Job and Node ownership on behalf of admin Sep 10, 2018 3:03:22 PM hudson.model.UpdateCenter$UpdateCenterConfiguration download INFO: Downloading Job and Node ownership Sep 10, 2018 3:03:23 PM hudson.PluginManager dynamicLoad INFO: Attempting to dynamic load /var/jenkins_home/plugins/ownership.jpi Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Listed all plugins Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Prepared all plugins Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Loaded all jobs Sep 10, 2018 3:03:23 PM jenkins.InitReactorRunner$1 onAttained INFO: Completed initialization Sep 10, 2018 3:03:23 PM hudson.PluginManager dynamicLoad INFO: Plugin ownership:0.12.1 dynamically installed Sep 10, 2018 3:03:23 PM hudson.model.UpdateCenter$DownloadJob run INFO: Installation successful: Job and Node ownership Add Comment
[JIRA] (JENKINS-53466) ownership-plugin loading failure on startup
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-53466 ownership-plugin loading failure on startup Issue Type: Bug Assignee: Oleg Nenashev Attachments: ownership-config-KO.png, ownership-config-OK.png, ownership-KO.xml, ownership-OK.xml, plugins.txt Components: ownership-plugin Created: 2018-09-07 12:57 Environment: jenkins/jenkins:lts (2.121.3) ownership-plugin 0.12.1 matrix-auth 2.3 Priority: Major Reporter: Thomas de Grenier de Latour Oownership plugin (0.12.1) fails to load (on Jenkins startup) when a matrix is configured in "Setup default permissions for jobs item-specific security" / "Enable project-based security". Here is jenkins.log when it fails: Sep 07, 2018 10:41:14 AM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization Sep 07, 2018 10:41:14 AM jenkins.InitReactorRunner$1 onAttained INFO: Listed all plugins Sep 07, 2018 10:41:15 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading plugin Job and Node ownership plugin v0.12.1 (ownership) java.io.IOException: Failed to initialize at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:542) at hudson.PluginManager$2$1$1.run(PluginManager.java:517) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296) at jenkins.model.Jenkins$5.runTask(Jenkins.java:1068)
[JIRA] (JENKINS-53136) Threads leak from cloudfoundry-plugin
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-53136 Threads leak from cloudfoundry-plugin Issue Type: Bug Assignee: Olivier Lamy Components: cloudfoundry-plugin Created: 2018-08-20 14:24 Environment: Jenkins 2.107.3 cloudfoundry-plugin 2.2.1 Priority: Minor Reporter: Thomas de Grenier de Latour I came across a small Jenkins instance with the Cloudfoundry plugin installed, which was starting to use more memory than usual. The JVM threads dump (kill -3) shows 448 threads like this one: "cloudfoundry-client-nio-1" #83131 daemon prio=5 os_prio=0 tid=0x7f1a790b0800 nid=0x2e83 runnable [0x7f1a50077000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0xe761c9f0> (a io.netty.channel.nio.SelectedSelectionKeySet) - locked <0xe761daa8> (a java.util.Collections$UnmodifiableSet) - locked <0xe761c8f8> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:62) at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:752) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:408) at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) at java.lang.Thread.run(Thread.java:745)
[JIRA] (JENKINS-50600) Infinite loop with crontab (day-of-month out of range for previous month)
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-50600 Infinite loop with crontab (day-of-month out of range for previous month) Issue Type: Bug Assignee: Unassigned Components: core Created: 2018-04-05 16:40 Environment: Jenkins 2.89.4 OpenJDK 8 (8u111) Priority: Minor Reporter: Thomas de Grenier de Latour I came across a Jenkins master process with several spinning threads like this: "Handling GET /jenkins/job//descriptorByName/hudson.triggers.TimerTrigger/checkSpec from AA.BB.CC.DD : RequestHandlerThread[#297]" Id=8467 Group=main RUNNABLE at java.lang.Object.clone(Native Method) at java.util.Calendar.clone(Calendar.java:3287) at java.util.GregorianCalendar.clone(GregorianCalendar.java:2003) at java.util.Calendar.getMillisOf(Calendar.java:3408) at java.util.Calendar.compareTo(Calendar.java:2784) at hudson.scheduler.CronTab.floor(CronTab.java:400) at hudson.scheduler.CronTabList.previous(CronTabList.java:134) at hudson.triggers.TimerTrigger$DescriptorImpl.updateValidationsForNextRun(TimerTrigger.java:109) at hudson.triggers.TimerTrigger$DescriptorImpl.doCheckSpec(TimerTrigger.java:93) ... I've found the corresponding request in Apache logs: AA.BB.CC.DD - [28/Mar/2018:17:20:45 +0200] "GET
[JIRA] (JENKINS-42093) Can't work in workspace with spaces
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-42093 Re: Can't work in workspace with spaces proposed fix: https://github.com/jenkinsci/ssh-agent-plugin/pull/19 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-38938) Add option for global data directory
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-38938 Re: Add option for global data directory Tested with success on a snapshot build, it works fine for the use-case described in PR 596. Thanks for implementing that! 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-26008) Use of compression during copying of artifacts cut throughput by a factor of 3
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-26008 Re: Use of compression during copying of artifacts cut throughput by a factor of 3 Just closed JENKINS-30815 as a duplicate of this one, after Carl George pointed it to me. But you can still have a look there for more evidence of how undesirable this compression can be in some cases. 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-30815) GZip compression of master-slave transfer should be optional
Title: Message Title Thomas de Grenier de Latour closed an issue as Duplicate Yes, thanks, you're absolutely right, my issue is a duplicate. Closing it. Jenkins / JENKINS-30815 GZip compression of master-slave transfer should be optional Change By: Thomas de Grenier de Latour Status: Open Closed Resolution: Duplicate 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
[JIRA] (JENKINS-26578) Adjuncts do not include CSS correctly for removable dom fragments
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-26578 Re: Adjuncts do not include CSS correctly for removable dom fragments stephenconnolly: I think there is an issue with the JS hack introduced in select.js in your last commit, for applying new behaviours to existing DOM elements. You should call Behaviour.applySubtree with includeSelf=true, otherwise it will not apply one of the specified behaviours (the one for "DIV.credentials-select-control" itself). I opened a PR which does that (PR-67), referring to JENKINS-37707 (which is an issue with credentials-binding-plugin when trying to bind credentials to a project and the credentials selection code is loaded for the first time in the job configuration page). Tell me if you need me to edit the PR to refer to this issue instead, it's just that I've only found it afterward. To reproduce the issue and test the fix, here is what I did: get master sources for credentials-binding-plugin bump jenkins.version to 1.609 and credentials version to 2.1.4 hpi:run, create a login/password credentials, create a freestyle job, try to bind the secret to a combined variable (for instance) => it should give you the error reported in JENKINS-37707 build credentials 2.1.5-SNAPSHOT with my fix, bump dependency in credentials-binding-plugin, and repeat previous step => it should work fine Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37707) Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-37707 Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed Change By: Thomas de Grenier de Latour Component/s: credentials-plugin 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-37707) Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-37707 Re: Saving SecretBuildWrapper for the first time fails due to duplicated credentialsId field unless git also installed I think I've understood what the issue is. I've opened a PR for the credentials-plugin, because the issue seems to be in the JS library of the /lib/credentials:select Jelly tag. https://github.com/jenkinsci/credentials-plugin/pull/67 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] [disk-usage-plugin] (JENKINS-30830) wrong path in html output to directory16.png
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-30830 Re: wrong path in html output to directory16.png This issue has been fixed by this PR: https://github.com/jenkinsci/disk-usage-plugin/pull/34 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [disk-usage-plugin] (JENKINS-30934) Changing crontab settings blocks "configSubmit" for 3x60 seconds
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-30934 Changing crontab settings blocks "configSubmit" for 3x60 seconds Issue Type: Bug Assignee: Lucie Votypkova Components: disk-usage-plugin Created: 13/Oct/15 9:11 PM Priority: Major Reporter: Thomas de Grenier de Latour With recent disk-usage plugin (0.26+), changing the crontab expressions in the global settings will block Jenkins configuration for (up to) 180 seconds (when the 3 crontab settings are modified at once). Taking several thread-dumps when it happens shows, successively, the following three stacks: "Handling POST /jenkins/configSubmit from 127.0.0.1 : RequestHandlerThread[#14]" daemon prio=10 tid=0x7f2c4820d000 nid=0x3311 waiting on condition [0x7f2c2e7dd000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at hudson.plugins.disk_usage.DiskUsageCalculation.reschedule(DiskUsageCalculation.java:101) at hudson.plugins.disk_usage.DiskUsageProjectActionFactory$DescriptorImpl.configureBuildsCalculation(DiskUsageProjectActionFactory.java:359) at hudson.plugins.disk_usage.DiskUsageProjectActionFactory$DescriptorImpl.configure(DiskUsageProjectActionFactory.java:293) at jenkins.model.Jenkins.configureDescriptor(Jenkins.java:2899) at jenkins.model.Jenkins.doConfigSubmit(Jenkins.java:2862) ...
[JIRA] [disk-usage-plugin] (JENKINS-30934) Changing crontab settings blocks "configSubmit" for 3x60 seconds
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-30934 Re: Changing crontab settings blocks "configSubmit" for 3x60 seconds I don't understand (at all) the purpose of this sleep calls (is it some testing/debugging code which should have been removed before commit?), thus I'm not able to submit a PR. Actually, since "it's testing code" is the only explanation I can think of, I've submitted a PR to drop it: https://github.com/jenkinsci/disk-usage-plugin/pull/37 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-30815) GZip compression of master-slave transfer should be optional
Title: Message Title Thomas de Grenier de Latour updated an issue Jenkins / JENKINS-30815 GZip compression of master-slave transfer should be optional Change By: Thomas de Grenier de Latour Summary: GZip compression of master-slave transfer should be optionnal optional Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-30815) GZip compression of master-slave transfer should be optionnal
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-30815 GZip compression of master-slave transfer should be optionnal Issue Type: Improvement Assignee: Unassigned Attachments: flamegraph-1.svg, flamegraph-2.svg Components: core Created: 06/Oct/15 4:32 PM Priority: Minor Reporter: Thomas de Grenier de Latour When artifacts are archived at the end of a build (hudson.tasks.ArtifactArchiver), they get transferred from the slave to the master through a stream of gzipped tar data (jenkins.model.StandardArtifactManager calling hudson.FilePath.copyRecursiveTo). While I understand the intent of the involved compression (using some CPU to reduce bandwidth usage), I think it's not always the right thing to do: in some (many?) cases, the biggest artifacts are already compressed (.jar/.deb/.rpm/...), and gzipping the stream won't really reduce its length in some cases, bandwidth is much less an issue than CPU (think co-located master and slave VMs on an very loaded host)
[JIRA] [subversion-plugin] (JENKINS-30197) Migration from Subversion 1.x to 2.5.1+ can fail (ClassCastException on SCM)
Title: Message Title Thomas de Grenier de Latour created an issue Jenkins / JENKINS-30197 Migration from Subversion 1.x to 2.5.1+ can fail (ClassCastException on SCM) Issue Type: Bug Assignee: Unassigned Components: subversion-plugin Created: 28/Aug/15 12:25 PM Priority: Major Reporter: Thomas de Grenier de Latour The Credentials migration code added in subversion-plugin 2.5.1 fails when hitting a job which is not (anymore?) using SubversionSCM, but which still has a subversion.credentials file in its job directory. SEVERE: Failed SubversionSCM.perJobCredentialsMigration java.lang.Error: java.lang.reflect.InvocationTargetException at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:109) at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:169) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282) at jenkins.model.Jenkins$7.runTask(Jenkins.java:903) 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:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.reflect.InvocationTargetException 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:606) at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105) ... 8 more Caused
[JIRA] [git-client-plugin] (JENKINS-20879) SSH Credentials (private key with passphrase) do not work
Title: Message Title Thomas de Grenier de Latour edited a comment on JENKINS-20879 Re: SSH Credentials (private key with passphrase) do not work HereisanattemptatfixingpollingwithGitCliandapassphrase-protectedSSHprivatekey:https://github.com/jenkinsci/git-client-plugin/pull/168WorksformeonUbuntu12.04 ,withthispatchontopofthegit-client-plugin1 . 17.1andgit-plugin2.3.5(andgit2.4.0fromthegit-corePPA). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [git-client-plugin] (JENKINS-20879) SSH Credentials (private key with passphrase) do not work
Title: Message Title Thomas de Grenier de Latour commented on JENKINS-20879 Re: SSH Credentials (private key with passphrase) do not work Here is an attempt at fixing polling with GitCli and a passphrase-protected SSH private key: https://github.com/jenkinsci/git-client-plugin/pull/168 Works for me on Ubuntu 12.04. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
