-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.73.3 LTS, ActiveChoicesPlugin 2.0, cloudbees-folder 5.18, CentOS 7
Hello,
The Jenkins jobs we are using with active-choices-plugin (reactive) are stored within a cetrain folder structure, which is enabled by cloudbees-folder plugin. There may be several jobs with the same name. Sample Jenkins folder structure:
/RootFolder1/SubFolder1/Job1
/RootFolder1/SubFolder2/Job1
/RootFolder2/SubFolder1/Job1
/Job1
For a hudson.model.Project, getName() would return "Job1" and getFullName() would return the whole Pathname.
This seems to make a difference while using the jenkinsProject binding, which evaluates based on the getName(). During my test this was correctly evaluated only if "Job1" was at the topmost level of hierarchy, not in any folder. (Our use case is easily obtaining the customWorkspace value from jenkinsProject dynamically... and this was just a side effect)
In method getProjectByName(), currently the condition checked is "p.getName().equals(projectName)".
Please consider using "p.getFullName().equals(projectName)" instead in case of folder hierarchy.
Looks like this is affected by the AbstractScriptableParameter inherited constructor, being the origin of the projectName value using AbstractItem.getName() - please consider using getFullName() instead.
Thanks a lot!
**Hi benediktnagy! Thanks for the detailed report.
It sounds like a good idea, but I would need to review the javadocs and understand what would be the impact for users for vanilla job types, and also of custom jobs created by other plug-ins.
Next release is a bug fix, including a regression. So will aim at working on this issue in the next release. Could you help with testing?
Thanks!!