[JIRA] (JENKINS-41940) Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies

7 views
Skip to first unread message

vitali.gontsharuk@reiterate.de (JIRA)

unread,
Feb 10, 2017, 1:34:01 PM2/10/17
to jenkinsc...@googlegroups.com
Vitali Gontsharuk updated an issue
 
Jenkins / New Feature JENKINS-41940
Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Change By: Vitali Gontsharuk
Summary: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

unread,
Feb 10, 2017, 2:27:03 PM2/10/17
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Feb 15, 2017, 12:09:01 PM2/15/17
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Unassigned
 

stage is only for display. I think you are talking about node. Could perhaps be supported somehow in this plugin, TBD.

I think the approach is misconceived, though. Better to have a QueueTaskDispatcher which blocks off executor slots dynamically based on measured system load or something.

Change By: Jesse Glick
Component/s: heavy-job-plugin
Component/s: pipeline-stage-step-plugin
Labels: executor pipeline stage weight
Assignee: Jesse Glick

vitali.gontsharuk@reiterate.de (JIRA)

unread,
Feb 15, 2017, 12:32:01 PM2/15/17
to jenkinsc...@googlegroups.com
Vitali Gontsharuk commented on New Feature JENKINS-41940
 
Re: Pipeline stages should be configurable with a weight property, corresponding to the number of executors the stage occupies

Well, I was using the abstractions from Declarative Pipeline here. You obviously know better how this is mapped to Scripted Pipeline primitives.

Concerning the approach: I have basically proposed the same functionality as currently exists for Freestyle jobs to be supported for Pipeline jobs. This is not a very fancy approach, but it is enough to get the job done in practice. If the same goal could be reached automatically, without any configuration from the user, that would be just perfect.

What do you think, would it be a lot of effort to implement?

vitali.gontsharuk@reiterate.de (JIRA)

unread,
Feb 15, 2017, 12:42:02 PM2/15/17
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Feb 15, 2017, 1:49:01 PM2/15/17
to jenkinsc...@googlegroups.com

Thorsten@meinl.bnv-bamberg.de (JIRA)

unread,
Feb 22, 2017, 10:52:01 AM2/22/17
to jenkinsc...@googlegroups.com

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 }

}}

Thorsten@meinl.bnv-bamberg.de (JIRA)

unread,
Feb 22, 2017, 10:53:01 AM2/22/17
to jenkinsc...@googlegroups.com
Thorsten Meinl edited a comment on New Feature JENKINS-41940
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 }
}}
_

Thorsten@meinl.bnv-bamberg.de (JIRA)

unread,
Feb 22, 2017, 10:54:02 AM2/22/17
to jenkinsc...@googlegroups.com
Thorsten Meinl edited a comment on New Feature JENKINS-41940
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}

Thorsten@meinl.bnv-bamberg.de (JIRA)

unread,
Feb 22, 2017, 10:54:02 AM2/22/17
to jenkinsc...@googlegroups.com
Thorsten Meinl edited a comment on New Feature JENKINS-41940
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}

vitali.gontsharuk@reiterate.de (JIRA)

unread,
Feb 22, 2017, 12:03:01 PM2/22/17
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Feb 22, 2017, 5:20:01 PM2/22/17
to jenkinsc...@googlegroups.com

jayspang@amazon.com (JIRA)

unread,
Mar 15, 2018, 4:41:02 PM3/15/18
to jenkinsc...@googlegroups.com

Just commenting that this is a feature we want as well. We used to use the Heavy Job Plugin, which did exactly what we need. We had to leave it behind when moving to pipelines.

Our Jenkins instance has ~30 jobs, and almost all of them are relatively lightweight and can run in parallel with other jobs. However, 2-3 of them are large C++ compiles, which are very resource intensive and should NOT share the node with other jobs.

In this situation, my choices are...

1) Give my nodes only 1 executor. This results in lots of wasted capacity, as I have to spin up LOTS of nodes to ensure I can meet peak demand.

2) Give my nodes multiple executors. This results in frequent "slow builds" as Jenkins occasionally decides to run 2 compiles on the same node.

Being able to say "this job is heavy and cannot share a node" would mitigate these pain points.

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

jayspang@amazon.com (JIRA)

unread,
Mar 15, 2018, 4:42:04 PM3/15/18
to jenkinsc...@googlegroups.com
Jay Spang edited a comment on New Feature JENKINS-41940
Just commenting that this is a feature we want as well. We used to use the [Heavy Job Plugin|https://plugins.jenkins.io/heavy-job], which did exactly what we need. We had to leave it behind when moving to pipelines. :(


Our Jenkins instance has ~30 jobs, and almost all of them are relatively lightweight and can run in parallel with other jobs. However, 2-3 of them are large C++ compiles, which are very resource intensive and should NOT share the node with other jobs.
In this situation, my choices are...

1) Give my nodes only 1 executor. This results in lots of wasted capacity, as I have to spin up LOTS of nodes to ensure I can meet peak demand.
 

2) Give my nodes multiple executors. This results in frequent "slow builds" as Jenkins occasionally decides to run 2 compiles on the same node.

Being able to say "this job is heavy and cannot share a node" would mitigate these pain points.

wcmclen@sandia.gov (JIRA)

unread,
Sep 6, 2018, 5:49:04 PM9/6/18
to jenkinsc...@googlegroups.com

Just adding my comment that something like this would be really useful for us on our end.

We have some large templated codes that eat a lot of ram when building, and it's bad if we get 2 or 3 make -j 30's queued up on the same build slave so being able to set the job weight in our pipeline jobs would enable us to move more of our testing environment into a pipeline system.

If there was a way to do something like:  

node(label: "node_label", weight: 30) { do-my-30-core-build }

  life would be pretty good.

 

 

 

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

wcmclen@sandia.gov (JIRA)

unread,
Dec 12, 2019, 7:51:03 PM12/12/19
to jenkinsc...@googlegroups.com

Jean-Paul G I will try out your hack, I'm not sure what happens though if your 'node' is really just a label that might include several machines.  For example, we often have labels such as "rhel7" and may have many red hat 7 systems in the build farm under that label so Jenkins can just schedule a build where there are available nodes.
So if I have three 20-core machines under that label and four jobs with a build weight of 15 cores, what I'd want is for the first 3 jobs to run and the fourth to wait until it can fit on a machine. Do you know if your script would do that or would I get 3 machines with 15 executors taken for the first three jobs and then the 4th job taking 5 executors from each machine?

Still would be nice if the pipeline plugin had a weight parameter to the node command

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

rocco.zanni@spreaker.com (JIRA)

unread,
Dec 26, 2019, 9:47:02 AM12/26/19
to jenkinsc...@googlegroups.com

Same issue here. We have a job that makes heavy use of the CPU cores, and being able to declare a specific number of executors required to run this pipeline will make our life way easier.

goganchic@gmail.com (JIRA)

unread,
Apr 27, 2020, 3:13:04 PM4/27/20
to jenkinsc...@googlegroups.com

Hello!

It would be very interesting for me to implement such plugin. I've looked through source code of Heavy Job Plugin and some examples of Pipeline API like lockable-resources-plugin. Unfortunately Pipeline API differs from Freestyle Projects. For now it's clear how to create custom step and wrap another step with it but I can't understand how to create something like subtasks in Heavy Job plugin.

I would be very happy if someone can explain me this moment a bit more or give me a useful link.

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages