jenkinsci / jenkinsci/workflow-durable-task-step-plugin
[JENKINS-73618] ws step re-provisions already provisioned workspace if controller restarted in midway during build
- Dominant language
- Java
- Stars
- 46
- Forks
- 110
- PR merge metrics
- No merged PRs in 30d
Description
The `ws` step leases a workspace path, if the same path is asked to be leased again when one lease is already active; the `ws` step will lease with attaching `@2`.
However the same path can be leased again, when the first lease is still existing, if the controller is restarted mid-way of the build.
Steps to reproduce
- Attach an agent to jenkins controller, and run the below pipeline.
- When the pipeline enters first `ws` scope, it will print a log saying restart the controller. Restart the controller. However the build will still keep going on the agent.
- controller comes online and logs will show the pipeline entered the second `ws` , but leased the same workspace.
- pipeline code
String wSpacePath = "/tmp/my-workspace"
int sleepSeconds = 100node("spider-agent1") {
ws(wSpacePath) {
echo "Sleeping for 100 secs; restart jenkins now, but keep the agent running. The same workspace will be leased again in the nested ws"
sleep sleepSeconds
ws(wSpacePath) {
echo "Executing inside nested workspace, pipeline completed"
}
}
}
The same issue can be reproduced in another way too.
If a pipeline with a single `ws` is scheduled on agent with 2 executors, and controller restarts midway. When the controller comes online, start another build on the same agent. Two parallel builds will be running on the same agent, both will lease the same workspace in the `ws` step.
If the controller wasn't restarted, `ws` would lease workspace with `@2` in the second build - which is the expected behavior.
It is possible that this bug occurred during this change: https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/180
---
Originally reported by
gbhat, imported from: ws step re-provisions already provisioned workspace if controller restarted in midway during build
Raw content of original issue
The `ws` step leases a workspace path, if the same path is asked to be leased again when one lease is already active; the `ws` step will lease with attaching `@2`.
However the same path can be leased again, when the first lease is still existing, if the controller is restarted mid-way of the build.
Steps to reproduce
- Attach an agent to jenkins controller, and run the below pipeline.
- When the pipeline enters first `ws` scope, it will print a log saying restart the controller. Restart the controller. However the build will still keep going on the agent.
- controller comes online and logs will show the pipeline entered the second `ws` , but leased the same workspace.
- pipeline code
String wSpacePath = "/tmp/my-workspace"
int sleepSeconds = 100node("spider-agent1") {
ws(wSpacePath) {
echo "Sleeping for 100 secs; restart jenkins now, but keep the agent running. The same workspace will be leased again in the nested ws"
sleep sleepSeconds
ws(wSpacePath) {
echo "Executing inside nested workspace, pipeline completed"
}
}
}
The same issue can be reproduced in another way too.
If a pipeline with a single `ws` is scheduled on agent with 2 executors, and controller restarts midway. When the controller comes online, start another build on the same agent. Two parallel builds will be running on the same agent, both will lease the same workspace in the `ws` step.
If the controller wasn't restarted, `ws` would lease workspace with `@2` in the second build - which is the expected behavior.
It is possible that this bug occurred during this change: https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/180
2 attachments
- [run_build_with_restart.jpg](https://issues.jenkins.io/secure/attachment/63143/run_build_with_restart.jpg)
> 
- [run_build_without_restart.jpg](https://issues.jenkins.io/secure/attachment/63144/run_build_without_restart.jpg)
> 
Contributor guide
Assessment
This issue has not been assessed yet.