JENKINS-36479 - clean up hard killed/deleted builds' locks #34
Conversation
When we try to lock, check if the resource is locked by either a null build or a build that's no longer running. If so, unlock the resource before continuing. This probably needs a *lot* more work. It's just a first thought.
Note - test needs to be reworked to actually fail if it can't get the lock. Right now it'll hang forever. I'll figure that out!
JenkinsRule tests time out after 180 seconds anyway, it turns out. Would prefer to have a shorter timeout than that, but it works, so hey.
|
Oh, and I've verified that the tests fail against master, so that's nice. =) |
| && (lockingRun == null | ||
| || !lockingRun.isBuilding() | ||
| || lockingRun.getParent().getBuild(lockingRun.getId()) == null)) { | ||
| performUnlocking(r, lockingRun, inversePrecedence); |
There was a problem hiding this comment.
Should probably at least print a warning in this build’s log.
|
I think you could use |
|
I tried some experiments with |
|
Oh, yeah, it's not because |
|
Hmm - looks like changing all the |
|
Huh? This code should fire for any |
|
Oh you mean |
|
Gonna do an alternate pr for that approach and leave this open for the moment. |
| WorkflowRun b3 = p3.scheduleBuild2(0).waitForStart(); | ||
|
|
||
| // Verify that b2 gets the lock. | ||
| story.j.waitForMessage("Lock acquired on [resource1]", b2); |
There was a problem hiding this comment.
So, b2 is getting the lock because b3 release it before, right? Weird that a new build is required to unlock builds already waiting for the resource. Acceptable I guess, but weird.
|
Closing in favor of #35 |
JENKINS-36479
cc @reviewbybees, esp @jglick and @amuniz