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

Shared Library checkout skipping exact Git tag match

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      We were trying to use a Git-based shared library in Jenkins at a certain tag. In this case, we were trying to checkout the tag "2", but it chose "2.0.5" instead, which is not what we wanted:
       

      Loading library JenkinsScripts@2
      Attempting to resolve 2 from remote references... > git --version # timeout=10 
      > git ls-remote -h -t – https://our-repo.git # timeout=10
       Candidate partial match: refs/tags/2.0.5 revision 280c1ed276d8cc9d314b312547ddf960b02fe2e7
       Found match: refs/tags/2 revision 7fa2a841b2d38165a0ed28e8671451fea6
       Selected match: 2.0.5 revision 280c1ed276d8cc9d314b312547ddf960b02fe2e7
       Resolving tag commit... (remote references may be a lightweight tag or an annotated tag)   
      
      # More output that's not relevant
      > git fetch --tags --progress – origin +refs/heads/:refs/remotes/origin/ # timeout=10
      > git rev-parse refs/tags/2.0.5^{commit} # timeout=10
       Resolved tag 2 revision 280c1ed276d8cc9d314b312547ddf960b02fe2e7
      

       
      You can see above that it found an exact tag match, but still selected the partial tag match of "2.0.5".
       
      Here's the raw git output we get if we run that ls-remote directly:

      $ git ls-remote -h -t – https://our-repo.git
       2554769 HEAD
       2554769 refs/heads/master
       79d78b0 refs/tags/2
       a387cfb refs/tags/2.0.0
       6b287b4 refs/tags/2.0.1
       38f18cf refs/tags/2.0.10
       a8c107d refs/tags/2.0.11
       ff6886e refs/tags/2.0.12
       861aa6a refs/tags/2.0.13
       c01866a refs/tags/2.0.14
       7fa2a84 refs/tags/2.0.15
       88a1ef9 refs/tags/2.0.2
       7ced43c refs/tags/2.0.3
       352a812 refs/tags/2.0.4
       280c1ed refs/tags/2.0.5
       d5c121c refs/tags/2.0.6
       4b9f5f0 refs/tags/2.0.7
       a756958 refs/tags/2.0.8
       019272b refs/tags/2.0.9

       
      It seems that if the a partial tag is found before the exact tag, it choses the partial one instead of the exact tag inside this loop:
      https://github.com/jenkinsci/git-plugin/blob/git-4.2.2/src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java#L842
       
      It will set shortHashMatch to 2.0.5's revision, and then when it finds the exact "match" of the "2" tag, it breaks out of the loop:

      https://github.com/jenkinsci/git-plugin/blob/git-4.2.2/src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java#L899

       
      But since shortHashMatch is set, it processes that first: 

      https://github.com/jenkinsci/git-plugin/blob/git-4.2.2/src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java#L920
       
      I would expect an exact tag match to take priority over a partial tag match.

        Attachments

          Activity

          Hide
          shokeeb Shokeeb Yaqub added a comment - - edited

          Any update on this?

          We have just run into a similar issue. Our tag was 741 but the plugin has 'matched' with the first three characters of a previous commit rather than the tag specified

           

          Loading library library@741
           Attempting to resolve 741 from remote references...
           > git --version # timeout=10
           using GIT_ASKPASS to set credentials ops github token
           > git ls-remote – #OUR REPO URL # timeout=10
           Candidate partial match: refs/tags/604 revision 741c257b24af3ee125312bd9739e2106fd010245
           Found match: refs/tags/741 revision ec3788d0e43f51511b80034cbe51fabdc9796ffa
          Selected match: 604 revision 741c257b24af3ee125312bd9739e2106fd010245
           Resolving tag commit... (remote references may be a lightweight tag or an annotated tag)
           
          Show
          shokeeb Shokeeb Yaqub added a comment - - edited Any update on this? We have just run into a similar issue. Our tag was 741 but the plugin has 'matched' with the first three characters of a previous commit rather than the tag specified   Loading library library@741 Attempting to resolve 741 from remote references... > git --version # timeout=10 using GIT_ASKPASS to set credentials ops github token > git ls-remote – #OUR REPO URL # timeout=10 Candidate partial match: refs/tags/604 revision 741c257b24af3ee125312bd9739e2106fd010245 Found match: refs/tags/741 revision ec3788d0e43f51511b80034cbe51fabdc9796ffa Selected match: 604 revision 741c257b24af3ee125312bd9739e2106fd010245 Resolving tag commit... (remote references may be a lightweight tag or an annotated tag)  
          Hide
          markewaite Mark Waite added a comment -

          No update. Pull requests proposing tests that show the behavior and a fix for the behavior are welcomed.

          Show
          markewaite Mark Waite added a comment - No update. Pull requests proposing tests that show the behavior and a fix for the behavior are welcomed.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              harmon Adam Grant
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: