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

Shared Library checkout skipping exact Git tag match

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      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.

          [JENKINS-62592] Shared Library checkout skipping exact Git tag match

          Adam Grant created issue -
          Adam Grant made changes -
          Description Original: 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|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

           > 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|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.
          New: 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:
            
          {code:java}
          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
          {code}
           
           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:
          {code:java}
          $ 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{code}

            
           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.
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]
          Noah Rozelle made changes -
          Assignee New: Noah Rozelle [ nrozelle ]

            nrozelle Noah Rozelle
            harmon Adam Grant
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: