-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins 2.263.1
Branch API 2.6.2
Forensics API Plugin 0.8.0
Git Forensics Plugin 0.8.0
Bitbucket Branch Source Plugin 2.9.6
If Jenkinsfile in a multibranch project "Folder/Repo" runs discoverGitReferenceBuild defaultBranch: 'release/1.41', then the Forensics API Plugin tries to find a job named "Folder/Repo/release/1.41". However, the branch "release/1.41" actually corresponds to the job "Folder/Repo/release%2F1.41"; the slash is encoded as "%2F". Because the name does not match, the Forensics API Plugin does not find the job.
[ReferenceFinder] There is no such job - maybe the job has been renamed or deleted?
(The 'release/1.41' string is not actually hardcoded in the Jenkinsfile.)
It looks like Forensics API Plugin 0.8.0 constructs the "Folder/Repo/release/1.41" string here: https://github.com/jenkinsci/forensics-api-plugin/blob/b1101561ba19c172d561704ae445a146c521cf88/src/main/java/io/jenkins/plugins/forensics/reference/ReferenceRecorder.java#L145
The Branch API plugin has a NameEncoder class that encodes the slash as "%2F".
I could perhaps work around this by running discoverGitReferenceBuild defaultBranch: 'release%2F1.41' instead, but I suspect that would break later if the Forensics API Plugin starts asking the Branch API which job corresponds to the specified branch. discoverGitReferenceBuild referenceJob: 'Folder/Repo/release%2F1.41' seems a safer workaround, although more complex to implement.
[JENKINS-64544] discoverGitReferenceBuild does not find job with encoded slashes like "release%2F1.41"
Kalle Niemitalo
added a comment - Or perhaps MultiBranchProject.getItemByBranchName (source, Javadoc), in case a derived class encodes the names differently.
Kalle Niemitalo
added a comment - Or perhaps MultiBranchProject.getItemByBranchName ( source , Javadoc ), in case a derived class encodes the names differently. If NameEncoder were not used directly, then the getReferenceBranch().equals(job.getName()) check would become getReferenceBranch().equals(((MultiBranchProject)topLevel). getProjectFactory().getBranch(job).getName()), I guess. That looks rather complex.
Kalle Niemitalo
added a comment - - edited If NameEncoder were not used directly, then the getReferenceBranch().equals(job.getName()) check would become getReferenceBranch().equals(((MultiBranchProject)topLevel). getProjectFactory().getBranch(job).getName()) , I guess. That looks rather complex. I see. In line 138 I already marked that as a TODO but as always I never found the time to implement that in the correct way.
Kalle Niemitalo
added a comment - If discoverJobFromMultiBranchPipeline uses MultiBranchProject.getItemByBranchName, then it cannot use SimpleReferenceRecorder.findJob and has to duplicate the message "There is no such job - maybe the job has been renamed or deleted?"
Kalle Niemitalo
added a comment - If discoverJobFromMultiBranchPipeline uses MultiBranchProject.getItemByBranchName, then it cannot use SimpleReferenceRecorder.findJob and has to duplicate the message "There is no such job - maybe the job has been renamed or deleted?" 
Yes, I think reusing the class from the branch-api plugin makes sense.