[JIRA] (JENKINS-8374) Launch slave using JNLP
Title: Message Title Thorsten Meinl commented on JENKINS-8374 Re: Launch slave using JNLP I want to continue the discussion on this feature request. I find that proposed enhancement quite appealing. We are currently reworking our Jenkins setup and will create custom AMIs for Windows that have all necessary tools installed (Java, Git, Maven, ...). It's trivial to also add an autostart script that starts a slave that connects to the master via JNLP. In fact I have that already working. The script takes the required connection information (master URL, slave name, and secret) from the instance's user data. Therefore the only piece that is missing is support for JNLP slaves in the EC2 plugin and the ability to start the instance with the correct user data. There are two major advantages over the current approach: It's much faster since WinRM isn't involved. It doesn't require SMB (especially not the almost dead SMB1 version) I am willing to work on a pull request for this feature if there are good chances that it will be integrated into the official release. Any opinions on that? 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.138484.1293642462000.21039.1557347700287%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-46089) ProcessTreeKiller broken in pipeline jobs
Title: Message Title Thorsten Meinl commented on JENKINS-46089 Re: ProcessTreeKiller broken in pipeline jobs It would be a real shame if this very useful functionality wasn't available in Pipeline jobs. We use it to deploy the full application stack after a build which can then be used for testing and playing around. Since we have many branches it's not feasible to set up environments outside of Jenkins and somehow deploy the build results. 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-42405) “Could not initialize class ProcessLiveness$LibC” running sh on Windows
Title: Message Title Thorsten Meinl commented on JENKINS-42405 Re: “Could not initialize class ProcessLiveness$LibC” running sh on Windows Well, everything works perfectly with Freestyle jobs under Windows. This essentially means, executing shell (bash) scripts under Windows isn't supported with pipelines? And I guess I cannot execute shell scripts with the bat command? Using batch files isn't an option. 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-23852) slave builds repeatedly broken by "hudson.remoting.ChannelClosedException: channel is already closed"
Title: Message Title Thorsten Meinl commented on JENKINS-23852 Re: slave builds repeatedly broken by "hudson.remoting.ChannelClosedException: channel is already closed" I have a vague feeling that this problem occurs when there is more than one job running on the slave. If I have time, I will try to restrict the Windows slaves to one slot and see if this makes the problem go away. Maybe some of you can try this, too. 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-23852) slave builds repeatedly broken by "hudson.remoting.ChannelClosedException: channel is already closed"
Title: Message Title Thorsten Meinl commented on JENKINS-23852 Re: slave builds repeatedly broken by "hudson.remoting.ChannelClosedException: channel is already closed" Since we switched from freestyle jobs to pipelines (a very decision if you as me), about every second jobs fails with this error which makes Windows slaves pretty much unusable. It has never been a problem before, therefore my guess is that is has something to do with pipelines. Here's a strack trace, which always looks the same: java.io.IOException: remote file operation failed: C:\Users\jenkins\slave\workspace\g.knime.product.full_master-6YACVMZPMCFFZKR6NNQZEQAJGOVHWVVS2MSXJGRRFPLNAY2WNRWQ at hudson.remoting.Channel@2eed4a92:Channel to /xxx.xxx.xxx.xxx hudson.remoting.ChannelClosedException: channel is already closed at hudson.FilePath.act(FilePath.java:992) at hudson.FilePath.act(FilePath.java:974) at hudson.FilePath.mkdirs(FilePath.java:1157) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:77) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:65) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:49) at hudson.security.ACL.impersonate(ACL.java:221) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:604) at hudson.remoting.Request.call(Request.java:130) at hudson.remoting.Channel.call(Channel.java:821) at hudson.FilePath.act(FilePath.java:985) ... 12 more Caused by: java.io.IOException: Unexpected EOF while receiving the data from the channel. FIFO buffer has been already closed at org.jenkinsci.remoting.nio.NioChannelHub$3.run(NioChannelHub.java:617) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) ... 5 more Caused by: org.jenkinsci.remoting.nio.FifoBuffer$CloseCause: Buffer close has been requested at org.jenkinsci.remoting.nio.FifoBuffer.close(FifoBuffer.java:426) at org.jenkinsci.remoting.nio.NioChannelHub$MonoNioTransport.closeR(NioChannelHub.java:332) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:565) ... 6 more I'm happy to debug this further if someone tells me what to do.
[JIRA] (JENKINS-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title Thorsten Meinl updated an issue Jenkins / JENKINS-42405 Lots of remote channel errors with pipelines and Windows slaves Change By: Thorsten Meinl Labels: regression 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-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title Thorsten Meinl commented on JENKINS-42405 Re: Lots of remote channel errors with pipelines and Windows slaves https://wiki.jenkins-ci.org/display/JENKINS/Logging 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-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-42405
Re: Lots of remote channel errors with pipelines and Windows slaves
After I figured out how to turn on more logging messages, I got this:{noformat}could not check C:\Users\jenkins\slave\workspace\r-WGI6TZZNQOBAAHSSLVRBWLNOVFN3FM5CSX5AJTOHIS4QEFKE2BPA@2java.io.IOException: Remote call on Channel to /172.17.xxx.xxx failed at hudson.remoting.Channel.call(Channel.java:830) at org.jenkinsci.plugins.durabletask.ProcessLiveness._isAlive(ProcessLiveness.java:77) at org.jenkinsci.plugins.durabletask.ProcessLiveness.isAlive(ProcessLiveness.java:59) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:198) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:307) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:276) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jenkinsci.plugins.durabletask.ProcessLiveness$LibC at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98) at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Thread.java:745) at ..remote call to Channel to /172.17.xxx.xxx(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:822) ... 12 more{noformat}
Add Comment
[JIRA] (JENKINS-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-42405
Re: Lots of remote channel errors with pipelines and Windows slaves
After I figured out to turn on more logging messages, I got this:{ { noformat} could not check C:\Users\jenkins\slave\workspace\r-WGI6TZZNQOBAAHSSLVRBWLNOVFN3FM5CSX5AJTOHIS4QEFKE2BPA@2java.io.IOException: Remote call on Channel to /172.17.xxx.xxx failed at hudson.remoting.Channel.call(Channel.java:830) at org.jenkinsci.plugins.durabletask.ProcessLiveness._isAlive(ProcessLiveness.java:77) at org.jenkinsci.plugins.durabletask.ProcessLiveness.isAlive(ProcessLiveness.java:59) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:198) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:307) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:276) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jenkinsci.plugins.durabletask.ProcessLiveness$LibC at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98) at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Thread.java:745) at ..remote call to Channel to /172.17.xxx.xxx(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:822) ... 12 more {noformat } }
Add Comment
[JIRA] (JENKINS-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title
Thorsten Meinl commented on JENKINS-42405
Re: Lots of remote channel errors with pipelines and Windows slaves
After I figured out to turn on more logging messages, I got this: {{could not check C:\Users\jenkins\slave\workspace\r-WGI6TZZNQOBAAHSSLVRBWLNOVFN3FM5CSX5AJTOHIS4QEFKE2BPA@2 java.io.IOException: Remote call on Channel to /172.17.xxx.xxx failed at hudson.remoting.Channel.call(Channel.java:830) at org.jenkinsci.plugins.durabletask.ProcessLiveness._isAlive(ProcessLiveness.java:77) at org.jenkinsci.plugins.durabletask.ProcessLiveness.isAlive(ProcessLiveness.java:59) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:198) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:307) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:276) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jenkinsci.plugins.durabletask.ProcessLiveness$LibC at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98) at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Thread.java:745) at ..remote call to Channel to /172.17.xxx.xxx(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:822) ... 12 more }}
Add Comment
[JIRA] (JENKINS-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-42405
Re: Lots of remote channel errors with pipelines and Windows slaves
After I figured out to turn on more logging messages, I got this:{{ could not check C:\Users\jenkins\slave\workspace\r-WGI6TZZNQOBAAHSSLVRBWLNOVFN3FM5CSX5AJTOHIS4QEFKE2BPA@2java.io.IOException: Remote call on Channel to /172.17.xxx.xxx failed at hudson.remoting.Channel.call(Channel.java:830) at org.jenkinsci.plugins.durabletask.ProcessLiveness._isAlive(ProcessLiveness.java:77) at org.jenkinsci.plugins.durabletask.ProcessLiveness.isAlive(ProcessLiveness.java:59) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:198) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:307) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:276) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jenkinsci.plugins.durabletask.ProcessLiveness$LibC at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98) at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Thread.java:745) at ..remote call to Channel to /172.17.xxx.xxx(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:822) ... 12 more}}
Add Comment
[JIRA] (JENKINS-16108) Option to use "last unstable" as fallback for "Upstream build which trigger" instead of only "last successful"
Title: Message Title Thorsten Meinl commented on JENKINS-16108 Re: Option to use "last unstable" as fallback for "Upstream build which trigger" instead of only "last successful" Any estimate when this will be fixed? In my opinion this is even a bug, because in Jenkins terms "successful" means stable or unstable (but not failed). However, the plug-in will only copy from the last stable job which may lead to unexpected results. 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-42407) Mailer step in pipelines doesn't send mails
Title: Message Title Thorsten Meinl created an issue Jenkins / JENKINS-42407 Mailer step in pipelines doesn't send mails Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2017/Mar/01 4:10 PM Environment: Jenkins 2.32.2 on Linux Pipeline 2.5 Pipeline Groovy 2.27 Pipeline Job 2.10 Pipeline Nodes and Processes 2.9 Pipeline Stage 2.2 Pipeline Stage 2.9 Priority: Minor Reporter: Thorsten Meinl Sending mails from pipeline jobs via the Mailer class doesn't work. Using this snippet step([$class: 'Mailer', notifyEveryUnstableBuild: true, recipients: 'me@mail']) just doesn't do anything. No error reported in the job, no errors in any logs and no mails delivered to the mail server. Sending mail at the end of freestyle jobs works as expected which indicates that this is a pipeline bug.
[JIRA] (JENKINS-42405) Lots of remote channel errors with pipelines and Windows slaves
Title: Message Title
Thorsten Meinl created an issue
Jenkins / JENKINS-42405
Lots of remote channel errors with pipelines and Windows slaves
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2017/Mar/01 4:06 PM
Environment:
Jenkins 2.32.2 Linux master, Windows slave Pipeline 2.5 Pipeline Groovy 2.27 Pipeline Job 2.10 Pipeline Nodes and Processes 2.9 Pipeline Stage 2.2
Priority:
Minor
Reporter:
Thorsten Meinl
I have two Windows slaves. When I run pipeline jobs on these slaves I get tons of error messages
Cannot contact Windows7: java.io.IOException: Remote call on Channel to /172.17.xxx.xxx failed
Yet the job finishes successfully. A minimal example to reproduce is
node('windows') {
stage('Test') {
sh '''
for ((i=0; i < 100; i++)); do
echo $i
sleep 1
done
'''
}
}
Executing the same shell script via a freestyle job on the same Windows slave works without any error messages therefore it's very likely that this is a bug in the pipeline implementation. Restarting slaves and master doesn't change anything. I also couldn't find any more information in log files (or I am
[JIRA] (JENKINS-41940) Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-41940
Re: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
As a workaround I'm currently using the following function: { quote code:java }def multiSlotNode(String label, int slots = 1, Closure body) { if (slots == 1) { node(label) { body() } } else if (slots > 1) { node(label) { multiSlotNode(env.NODE_NAME, slots - 1, body) } } else { throw new IllegalArgumentException("Number of slots must be greather than zero") }}{ quote code }Use as _multiSlotNode {code:java}multiSlotNode ('desired-node-label', 2) { doSomething } _ {code:java}
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-41940) Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-41940
Re: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
As a workaround I'm currently using the following function:{code:java}def multiSlotNode(String label, int slots = 1, Closure body) { if (slots == 1) { node(label) { body() } } else if (slots > 1) { node(label) { multiSlotNode(env.NODE_NAME, slots - 1, body) } } else { throw new IllegalArgumentException("Number of slots must be greather than zero") }}{code}Use as {code:java} multiSlotNode('desired-node-label', 2) { doSomething } {code:java}
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-41940) Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Title: Message Title
Thorsten Meinl edited a comment on JENKINS-41940
Re: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
As a workaround I'm currently using the following function: { { quote} def multiSlotNode(String label, int slots = 1, Closure body) { if (slots == 1) { node(label) { body() } } else if (slots > 1) { node(label) { multiSlotNode(env.NODE_NAME, slots - 1, body) } } else { throw new IllegalArgumentException("Number of slots must be greather than zero") }} {quote } } Use as {{multiSlotNode _multiSlotNode ('desired-node-label', 2) { doSomething } }} _
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-41940) Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Title: Message Title
Thorsten Meinl commented on JENKINS-41940
Re: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
As a workaround I'm currently using the following function: {{ def multiSlotNode(String label, int slots = 1, Closure body) { if (slots == 1) { node(label) { body() } } else if (slots > 1) { node(label) { multiSlotNode(env.NODE_NAME, slots - 1, body) } } else { throw new IllegalArgumentException("Number of slots must be greather than zero") } } }} Use as {{ multiSlotNode('desired-node-label', 2) { doSomething } }}
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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title Thorsten Meinl edited a comment on JENKINS-37718 Re: Block Pipeline job while upstream or downstream projects are building No, there are good reason to split this into multiple jobs. One being that the support for multiple SCM checkouts from Git in Jenkins completely sucks. And maintainability. Every job has a Jenkinsfile that is about a hundred lines long. Combining it into one job makes it unreadable. Also the parallel step mixes the output of all nodes which renders it close to unreadable. Also being able to start the intermediate jobs individually isn't possible with one single pipeline job. Shall I continue ;-) 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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title Thorsten Meinl commented on JENKINS-37718 Re: Block Pipeline job while upstream or downstream projects are building No, there are good reason to split this into multiple jobs. One being that the support for multiple SCM checkouts from Git in Jenkins completely sucks. And maintainability. Every job has a Jenkinsfile that is about a hundred lines long. Combining it into one job makes it unreadable. Also the parallel step mixes the output of all nodes which renders it close to unreadable. Shall I continue 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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title Thorsten Meinl commented on JENKINS-37718 Re: Block Pipeline job while upstream or downstream projects are building I also don't see how Lockable Resources may replace this very useful functionality of FreeStyle jobs. Is there any reason, why you don't want to implement this for Pipeline jobs? Our use case is a chain of jobs such as B-C-D / \ A - E - F - G G combines the results from D and F and it doesn't make sense if either D or F (or any of their upstream jobs) are currently executing, because the current results will be replaced quite soon by new results. It doesn't hurt but it's a huge waste of resources. 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-41710) Annotate test results with a test run name
Title: Message Title Thorsten Meinl commented on JENKINS-41710 Re: Annotate test results with a test run name This is a very good idea and makes replacing matrix jobs with (parallel) pipelines easier. 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-41415) SCM changes of multiple checkouts via pipeline not shown correctly
Title: Message Title Thorsten Meinl created an issue Jenkins / JENKINS-41415 SCM changes of multiple checkouts via pipeline not shown correctly Issue Type: Bug Assignee: Mark Waite Components: git-plugin, pipeline Created: 2017/Jan/25 9:47 AM Environment: Jenkins 2.32.1 Pipeline 2.4 Git 3.0.1 Priority: Major Reporter: Thorsten Meinl With the new pipeline feature it's easily possible to check out several repositories in one job. This works as expected, but the "Changes" page of the job is completely empty. Also there are several "Git Build Data" links on the left (one for every checked out repository it seems) but all point to the same URL which (in our case) only shows the information for the first repository. This means you have no idea what you have actually built with a job unless you have a look at the console output, find all revision IDs and check the log of every repository manually. Add Comment
[JIRA] (JENKINS-9146) Allow archiving of empty directories to be enabled/disabled
Title: Message Title Thorsten Meinl commented on JENKINS-9146 Re: Allow archiving of empty directories to be enabled/disabled Another example where archiving empty directories is crucial: I have set up jobs that split a large Git repository into several smaller ones. I want to archive the results. However, empty folders such as "branches" or "refs" and not archive resulting in a broken Git repository (git commands simply don't recognize it as such any more). 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl resolved as Cannot Reproduce It seems the automatic "restart" that Jenkins performs after updating extensions isn't enough. After I completely restarted the service on the OS level, tokens are again replaced. Sorry for the noise. Jenkins / JENKINS-34267 Email-ext doesn'r replace all tokens any more Change By: Thorsten Meinl Status: Open Resolved Resolution: Cannot Reproduce 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl commented on JENKINS-34267 Re: Email-ext doesn'r replace all tokens any more Yes, I restarted after the update (Jenkins does this automatically). If you given me some pointers where to start looking, I can give it a try. 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl edited a comment on JENKINS-34267 Re: Email-ext doesn'r replace all tokens any more Jenkins configuration files are attached.BTW, if you perform a search on the internet for "$BUILD_STATUS" and "Jenkins" you will find quite a lot of hits that seem to indicate the same or a similar issue. 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl updated an issue Jenkins / JENKINS-34267 Email-ext doesn'r replace all tokens any more Jenkins configuration files Change By: Thorsten Meinl Attachment: hudson.plugins.emailext.ExtendedEmailPublisher.xml Attachment: config.xml 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl commented on JENKINS-34267 Re: Email-ext doesn'r replace all tokens any more Yes, it's on the latest version 1.12.1. 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] [email-ext-plugin] (JENKINS-34267) Email-ext doesn'r replace all tokens any more
Title: Message Title Thorsten Meinl created an issue Jenkins / JENKINS-34267 Email-ext doesn'r replace all tokens any more Issue Type: Bug Assignee: Alex Earl Components: email-ext-plugin Created: 2016/Apr/15 7:57 AM Environment: Jenkins 1.651.1 email-ext-plugin 2.41.3 Priority: Major Reporter: Thorsten Meinl After updating to version 2.41.3, tokens in email subjects are not replaced any more. Instead they are sent plain: $PROJECT_NAME - Build # 137 - $BUILD_STATUS! After downgrading to 2.40.5 they are again replaced correctly. Add Comment
[JIRA] [junit-plugin] (JENKINS-29138) JUnit analysis fails with OOM (regression)
Title: Message Title Thorsten Meinl created an issue Jenkins / JENKINS-29138 JUnit analysis fails with OOM (regression) Issue Type: Bug Assignee: Unassigned Components: junit-plugin Created: 30/Jun/15 8:24 AM Environment: Ubuntu 12.04, 64bit Labels: junit Priority: Major Reporter: Thorsten Meinl Since the upgrade to Jenkins 1.609.1 (LTS) Jenkins needs significantly more memory parsing the JUnit results. We have slaves running with 512MB heap and there were no problems parsing all results in the previous version. Right after the update they are not not able to parse the same results with 1.5GB! I also checked and the largest XML result file is 17MB (and we don't keep large stdout/stderr). This looks like a serious regression in this version of Jenkins. Here's the relevant stack trace: Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2367) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) at
[JIRA] [core] (JENKINS-25390) New design breaks build history layout
Thorsten Meinl commented on JENKINS-25390 New design breaks build history layout This also affects a few others parts of the GUI, e.g. the JUnit results page or the build processor panel on the front page. In some cases the layout gets better if you make the browser windows smaller. Should I open separate issues for each of them? 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] [core] (JENKINS-25390) New design breaks build history layout
Thorsten Meinl created JENKINS-25390 New design breaks build history layout Issue Type: Bug Assignee: Unassigned Attachments: broken_layout.png, ok.png Components: core Created: 31/Oct/14 8:48 AM Description: With the new design the build history panel on the left of each job is broken. It's rendered too small so that build date and build size are wrapped which looks darn-ugly. Funnily, if I make the browser window smaller it suddenly looks correct (see attached screenshots). Apart from that the new design seems to needs considerably more space, probably because the font size is larger (or because of the changed font). This is a drawback in my opinion. Environment: Jenkins 1.580.1 (LTS), Linux, Firefox 24.8 Project: Jenkins Priority: Minor Reporter: Thorsten Meinl 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] [core] (JENKINS-25390) New design breaks build history layout
Thorsten Meinl updated JENKINS-25390 New design breaks build history layout Another issue: the duration column in the tests view is also too small, see screenshot. It may be due to the german translation but still this was not problem before. Change By: Thorsten Meinl (31/Oct/14 8:52 AM) Attachment: duration_column_too_small.png 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] [core] (JENKINS-25390) New design breaks build history layout
Thorsten Meinl updated JENKINS-25390 New design breaks build history layout Another issue: the duration column in the tests view is also too small, see screenshot. It may be due to the german translation but still this was not problem before. Change By: Thorsten Meinl (31/Oct/14 8:52 AM) Attachment: duration_column_too_small.png 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.
