Locking pipeline without using executors
Opened this issue · 2 comments
What feature do you want to see added?
I run Jenkins in a kubernetes environment. I am trying to lock an entire pipeline so it runs as a single unit. I need this because I have multiple levels of priority of jobs, and need to be able to block execution of jobs in more than the single way allowed by the build-blocker plugin.
When running a simple pipeline like this:
pipeline {
agent any
options{
lock(resource: "shared_resource_lock",quantity:1,priority:0)
}
stages {
stage("test") {
steps {
sh("sleep 300")
}
}
}
}
If I have ten executors and build ten of these simultaneously, all ten executors will be busy, with 9 of them waiting on locks and blocking other buildable jobs. I would like the lock interpreted before being assigned an executor so that it's waiting in the queue and not blocking other buildable jobs.
Upstream changes
No response
Are you interested in contributing this feature?
No response
combination 'resource' && 'qauntity' makes no sense. You probably means 'label' && 'quantity'
So you shall created per node and executor one resource like
NodeName will be Debian12_01 with 4 executors
resource name | labels |
---|---|
Debian12_01_ex01 | Debian12_01 Debian12 |
Debian12_01_ex02 | Debian12_01 Debian12 |
Debian12_01_ex03 | Debian12_01 Debian12 |
Debian12_01_ex04 | Debian12_01 Debian12 |
Debian12_02_ex01 | Debian12_02 Debian12 |
Debian12_02_ex02 | Debian12_02 Debian12 |
Debian12_02_ex03 | Debian12_02 Debian12 |
Debian12_02_ex04 | Debian12_02 Debian12 |
lock like this shall fill your dreams
lock(label : 'Debian12', quantity : 1, variable: LOCKED_NODE, priority:0) {
String lockedNodeName = env.LOCKED_NODE;
lockedNodeName = lockedNodeName .substring(0, lockedNodeName .lastIndexOf("_ex"));
echo 'try to use executor on ' + lockedNodeName
node(env.LOCKED_NODE) {
sh("sleep 300");
}
}
note: I did not test the code, it is just a idea
note2: I use scripted pipeline. Not sure, how shall be it done in the delcarative pipeline.
mPokornyETM thank you for replying, but I think I have two problems:
- The executor has to start in order for it to be interpreted because I'm doing a declarative pipeline.
- The properties are not stored on the job itself, so have to be interpreted from the pipeline every time, which means an executor is required every time.