Test cases for JENKINS-41854#70
Conversation
|
@jglick Please let me know how else I can help to get this bug fixed. |
| }); | ||
| } | ||
|
|
||
| @Issue("JENKINS-41854") |
There was a problem hiding this comment.
Rather write a new test case, and mark it
@Ignore("TODO currently fails with: …")
@Issue("JENKINS-41854")There was a problem hiding this comment.
I've copied and pasted the existing test case into a new test case and marked it as suggested, leaving the existing test case untouched.
|
Offhand I think this would require changes in |
Thanks for explaining, @jglick. Has anyone committed to doing this work? I recognize I'm not the ideal person to work on a complicated change like this (I'm new to Jenkins development), but if nobody else has committed to doing this work I might be willing to give it a shot. I feel an obligation to my users, and this is a big pain point for them. I don't think it's wise for me to give this a shot on my own (given that I'm new to Jenkins development), but I could see this working out if someone was willing to mentor me to implement these changes. So is anyone willing to commit to either fixing the bug, or mentoring me to fix it? |
|
Hi @jglick, a gentle reminder regarding this pull request. |
dwnusbaum
left a comment
dwnusbaum
left a comment
There was a problem hiding this comment.
@basil Thanks for adding a reproduction case! I don't think anyone is currently working on the bug, but I also don't have enough knowledge of the necessary changes to be able to mentor you through fixing it. If you're feeling adventurous, you can open a work-in-progress PR that tries to implement Jesses' ideas in the ticket description, and we can try to give guidance there, but I really have no idea of how involved the fix would be.
|
Resolved a merge conflict with #73, will merge once the CI build passes. |
Test cases for JENKINS-41854
5 participants
Problem
JENKINS-41854 affects my production Jenkins servers at least once a month. My only recourse is to restart Jenkins, which rehydrates the
FilePathas described in the bug. Between the time that I hit the bug and the time I restart Jenkins, in-use workspaces are handed out to new jobs, causing both jobs to fail. I provided a detailed write-up of my experiences in JENKINS-50504, which I have now marked as a duplicate of JENKINS-41854 (I didn't know about JENKINS-41854 at the time).Solution
Work towards fixing the bug by writing a reproducible test case. This test case focuses on highlighting the two failure modes described in the bug:
shsteps in a node, then the secondshstep will fail.WorkspaceListlock needs to be acquired, after a newComputerbecomes available and hence a newWorkspaceList.Implementation
I found that the existing
buildShellScriptAcrossDisconnecttest could be extended to cover this bug, so I added some additional logic to it to demonstrate these two failure modes. I left the new logic commented out in places where it would currently cause the test to fail (until JENKINS-41854 is fixed). An alternative approach would have been to copy and paste the test into a new test, add the new logic there (without commenting it out), and skip the new test using@Ignore. Please let me know if you'd prefer that approach instead.Testing
When the "Back again" line is uncommented, the test fails as described in the bug (and with the same exception I see on my production Jenkins server with real jobs):
When the second
assertWorkspaceLockedis uncommented (even if the "Back again" line is still commented out), the test also fails as described in the bug because a freshWorkspaceListlock was not acquired and the [still in-use] workspace is handed out again: