Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
Jenkins 2.151
pipeline 2.5
pipeline-multibranch 2.20
-
-
2.1.1
Description
Something changed in the naming of the workspace folders on the Jenkins Master node. Previously, the name the was suffixed with a long random (names are examples only, the exact length is different):
MyProjectA1_MyBranch-ZOBMWQA2JSVUZRAPJAQ3NT3TSBIUQOS26N5CF3XJB@libs MyProjectA1_MyBranch-ZOBMWQA2JSVUZRAPJAQ3NT3TSBIUQOS26N5CF3XJB@script MyVeryLongBranchName-NHOUUZPM5MARPAN7OGASNLPNCKRLL26RQKEZIEEKC@libs MyVeryLongBranchName-NHOUUZPM5MARPAN7OGASNLPNCKRLL26RQKEZIEEKC@script MyVeryLongBranchName-TN6NSHXVGMKRKUOVV7CKNODZOK3JSHI4CQYCOR4E6@libs MyVeryLongBranchName-TN6NSHXVGMKRKUOVV7CKNODZOK3JSHI4CQYCOR4E6@script
However now, this suffix seems to be removed, causing name clashes when different repositories have long but identical branch names:
MyProjectA1_MyBranch@libs MyProjectA1_MyBranch@script MyVeryLongBranchName@libs <<-\ MyVeryLongBranchName@script | <<-\ MyVeryLongBranchName@libs <<-/ | MyVeryLongBranchName@script <<-/
The last two repositories are unrelated but map to the same directory, causing "unrelated repository" errors during checkout.
Attachments
Issue Links
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- links to
Activity
Josh Soref
added a comment - So, all I've done is rename workspaces.txt I don't really want to have to go to all 10 of my computers and delete entire trees if i can avoid it...
Josh Soref
added a comment - So, all I've done is rename workspaces.txt I don't really want to have to go to all 10 of my computers and delete entire trees if i can avoid it... Josh Soref
added a comment - So, I think that the plugin is not being careful about whose workspace.txt it's considering...
We're using
pipeline {
parallel {
stage {
}
stage {
}
}
}
A quick grep for our project across the various build nodes shows that the hashed directory listed is the one from one build node, but not from the failing build node (which has a different path in the workspaces.txt file).
Josh Soref
added a comment - So, I think that the plugin is not being careful about whose workspace.txt it's considering...
We're using
pipeline {
parallel {
stage {
}
stage {
}
}
}
A quick grep for our project across the various build nodes shows that the hashed directory listed is the one from one build node, but not from the failing build node (which has a different path in the workspaces.txt file). ralphtheninja yes the truncation is intentional, to limit the length of folder names, as some tools (especially, though not exclusively, on Windows) have trouble with long names.
jsoref please open a separate bug report linked to JENKINS-2111, ideally with steps to reproduce from scratch if you can find them. Your stack trace suggests that Jenkins is trying to open a workspaces.txt which does not exist…immediately after verifying that it does exist. While I could certainly make this code more defensive in various ways, I would like to understand what is happening first.
Thanks everyone for feedback. Jenkins seems to be a friendly and helpful community! <3
That's a terrible behavior.