Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64544

discoverGitReferenceBuild does not find job with encoded slashes like "release%2F1.41"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: forensics-api-plugin
    • Labels:
      None
    • Environment:
      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
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          drulli Ulli Hafner added a comment -

          Yes, I think reusing the class from the branch-api plugin makes sense.

          Show
          drulli Ulli Hafner added a comment - Yes, I think reusing the class from the branch-api plugin makes sense.
          Hide
          kon Kalle Niemitalo added a comment -

          Or perhaps MultiBranchProject.getItemByBranchName (source, Javadoc), in case a derived class encodes the names differently.

          Show
          kon Kalle Niemitalo added a comment - Or perhaps MultiBranchProject.getItemByBranchName ( source , Javadoc ), in case a derived class encodes the names differently.
          Hide
          kon 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.

          Show
          kon 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.
          Hide
          drulli Ulli Hafner added a comment -

          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. 

          Show
          drulli Ulli Hafner added a comment - 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. 
          Hide
          kon 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?"

          Show
          kon 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?"

            People

            Assignee:
            drulli Ulli Hafner
            Reporter:
            kon Kalle Niemitalo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: