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

Pipeline Job Cannot Checkout Git Tag

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I created a Pipeline project to build a Git project based on it's tag.

      node

      { git branch: 'refs/tags/VMAccess-1.4.1.0', url: 'https://github.com/azure/azure-linux-extensions' }

      The console output contains the following data.

      > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^

      {commit} # timeout=10
      > git rev-parse refs/remotes/origin/origin/refs/tags/VMAccess-1.4.1.0^{commit}

      # timeout=10
      > git rev-parse origin/refs/tags/VMAccess-1.4.1.0^

      {commit} # timeout=10

      The correct rev-parse should be refs/tags/VMAccess-1.4.1.0, but that value is never tried by the plugin. (The value refs/remotes/origin/refs/tags/VMAccess-1.4.1.0 may also be valid.) I tried to influence the refspec, but setting the refspec key in the git command, but this had no effect.

      I create a Freestyle project, and set the branch to refs/tags/VMAccess-1.4.1.0. The project built successfully.

      The console output contains the following data.

      > git rev-parse refs/tags/VMAccess-1.4.1.0^{commit}

      # timeout=10
      > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^

      {commit}

      # timeout=10
      Checking out Revision 97fb7b019946ef71f15e73881b761e4ba1933781 (refs/tags/VMAccess-1.4.1.0)

        Attachments

          Issue Links

            Activity

            boumenot Christopher Boumenot created issue -
            boumenot Christopher Boumenot made changes -
            Field Original Value New Value
            Description I created a Pipeline project to build a Git project based on it's tag.

            node {
                git branch: 'refs/tags/VMAccess-1.4.1.0', url: 'https://github.com/azure/azure-linux-extensions'
            }

            The console output contains the following data.

             > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10

            The correct rev-parse should be refs/tags/VMAccess-1.4.1.0, but that value is never tried by the plugin. (The value refs/remotes/origin/refs/tags/VMAccess-1.4.1.0 may also be valid.) I tried to influence the refspec, but setting the refspec key in the git command, but this had no effect.

            I create a Freestyle project, and set the branch to refs/tags/VMAccess-1.4.1.0. The project build successfully.

            The console output contains the following data.

             > git rev-parse refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
            Checking out Revision 97fb7b019946ef71f15e73881b761e4ba1933781 (refs/tags/VMAccess-1.4.1.0)

            I created a Pipeline project to build a Git project based on it's tag.

            node {
                git branch: 'refs/tags/VMAccess-1.4.1.0', url: 'https://github.com/azure/azure-linux-extensions'
            }

            The console output contains the following data.

             > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10

            The correct rev-parse should be refs/tags/VMAccess-1.4.1.0, but that value is never tried by the plugin. (The value refs/remotes/origin/refs/tags/VMAccess-1.4.1.0 may also be valid.) I tried to influence the refspec, but setting the refspec key in the git command, but this had no effect.

            I create a Freestyle project, and set the branch to refs/tags/VMAccess-1.4.1.0. The project built successfully.

            The console output contains the following data.

             > git rev-parse refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/refs/tags/VMAccess-1.4.1.0^{commit} # timeout=10
            Checking out Revision 97fb7b019946ef71f15e73881b761e4ba1933781 (refs/tags/VMAccess-1.4.1.0)

            markewaite Mark Waite made changes -
            Assignee Mark Waite [ markewaite ]
            Hide
            brad103 Brad M added a comment -

            This is a show-stopper for us before switching to pipeline builds for our packaging. In this case the plugin's parameter 'branch' is a bit limiting

            Show
            brad103 Brad M added a comment - This is a show-stopper for us before switching to pipeline builds for our packaging. In this case the plugin's parameter 'branch' is a bit limiting
            brad103 Brad M made changes -
            Priority Minor [ 4 ] Major [ 3 ]
            abayer Andrew Bayer made changes -
            Labels git pipeline tags workflow git pipeline tags
            michaelneale Michael Neale made changes -
            Remote Link This issue links to "cb details (Web Link)" [ 17305 ]
            michaelneale Michael Neale made changes -
            Labels git pipeline tags cloudbees-internal-pipeline git pipeline tags
            michaelneale Michael Neale made changes -
            Component/s pipeline [ 21692 ]
            michaelneale Michael Neale made changes -
            Link This issue relates to JENKINS-34395 [ JENKINS-34395 ]
            michaelneale Michael Neale made changes -
            Issue Type Bug [ 1 ] Improvement [ 4 ]
            Hide
            pmonsimi Pierre Monsimier added a comment - - edited

            Hello,

            A simple workaround is to execute the corresponding git commands, after retrieving the credentials via the withCredentials() syntax.
            Here is an example that worked for us :

             

                    withCredentials([usernamePassword(credentialsId: 'xxxxxx', passwordVariable: 'GIT_PASSWORD', usernameVariable: 'GIT_USERNAME')]) {
                        sh "if [ ! -d \"gitRepo\" ]; then git clone https://${GIT_USERNAME}:${GIT_PASSWORD}@gitRepo.adressToGitRepo/gitRpo.git; fi"
                        sh "git reset --hard origin/master"
                        sh "git pull origin master"
                        sh "git checkout tags/${TAG_VERSION}"
                    }
            
            

             

            Show
            pmonsimi Pierre Monsimier added a comment - - edited Hello, A simple workaround is to execute the corresponding git commands, after retrieving the credentials via the withCredentials() syntax. Here is an example that worked for us :           withCredentials([usernamePassword(credentialsId: 'xxxxxx' , passwordVariable: 'GIT_PASSWORD' , usernameVariable: 'GIT_USERNAME' )]) {             sh " if [ ! -d \" gitRepo\ " ]; then git clone https: //${GIT_USERNAME}:${GIT_PASSWORD}@gitRepo.adressToGitRepo/gitRpo.git; fi"             sh "git reset --hard origin/master"             sh "git pull origin master"             sh "git checkout tags/${TAG_VERSION}"         }  
            stephenconnolly Stephen Connolly made changes -
            Link This issue duplicates JENKINS-46207 [ JENKINS-46207 ]
            stephenconnolly Stephen Connolly made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Duplicate [ 3 ]
            Hide
            derrickgw Derrick Gibelyou added a comment -

            I don't think this is a duplicate of JENMINS-46207.  That ticket involved multi-branch automatically building tags.  The problem I am having is more general than that.

            I have a fairly complicated pipeline that requires checking out several dependent repos.  When I am working on a bug fix to a previously released version, I would like to point to the release tags in those other branches, but I am not able to.  This is because when I run the following in my script
             

            branchname = 'v_1.6_rc2'
            checkout([$class: 'GitSCM', branches: [[name: "*/$branchname:"]] ...
            

            It only calls rev-parse with the name of the remote prepended.  In this case the remote is called 'common':

            Current Directory = /local_home/jenkins/jobs/modelsim_compile_pipe/branches/bugfix.5hvtt7/workspace
            [Pipeline] checkout
            Wiping out workspace first.
            Cloning the remote Git repository
            Cloning repository git@gitlabee:firmware/common.git
             > git init /local_home/jenkins/jobs/modelsim_compile_pipe/branches/bugfix.5hvtt7/workspace/firmware/common # timeout=10
            Fetching upstream changes from git@gitlabee:firmware/common.git
             > git --version # timeout=10
            using GIT_SSH to set credentials Git Read-only key for Jenkins
             > git fetch --tags --progress git@gitlabee:firmware/common.git +refs/heads/*:refs/remotes/common/*
             > git config remote.common.url git@gitlabee:firmware/common.git # timeout=10
             > git config --add remote.common.fetch +refs/heads/*:refs/remotes/common/* # timeout=10
             > git config remote.common.url git@gitlabee:firmware/common.git # timeout=10
            Pruning obsolete local branches
            Fetching upstream changes from git@gitlabee:firmware/common.git
            using GIT_SSH to set credentials Git Read-only key for Jenkins
             > git fetch --tags --progress git@gitlabee:firmware/common.git +refs/heads/*:refs/remotes/common/* --prune
             > git rev-parse refs/remotes/common/release/v_1.6_rc2^{commit} # timeout=10
             > git rev-parse refs/remotes/common/common/release/v_1.6_rc2^{commit} # timeout=10
             > git rev-parse common/release/v_1.6_rc2^{commit} # timeout=10
            ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
            Finished: FAILURE
            

            When running manually I can do:

            > git rev-parse release/v_1.6_rc2
            8031a421b954a91fb7a74c7b78d76d6e578826b1
            

            Perhaps there is an attribute I can add to the checkout command to make it look for tags, but it doesn't seem to be documented, and it doesn't show up in the pipeline syntax snippet generator.

            Show
            derrickgw Derrick Gibelyou added a comment - I don't think this is a duplicate of JENMINS-46207.  That ticket involved multi-branch automatically building tags.  The problem I am having is more general than that. I have a fairly complicated pipeline that requires checking out several dependent repos.  When I am working on a bug fix to a previously released version, I would like to point to the release tags in those other branches, but I am not able to.  This is because when I run the following in my script   branchname = 'v_1.6_rc2' checkout([$class: 'GitSCM' , branches: [[name: "*/$branchname:" ]] ... It only calls rev-parse with the name of the remote prepended.  In this case the remote is called 'common': Current Directory = /local_home/jenkins/jobs/modelsim_compile_pipe/branches/bugfix.5hvtt7/workspace [Pipeline] checkout Wiping out workspace first. Cloning the remote Git repository Cloning repository git@gitlabee:firmware/common.git > git init /local_home/jenkins/jobs/modelsim_compile_pipe/branches/bugfix.5hvtt7/workspace/firmware/common # timeout=10 Fetching upstream changes from git@gitlabee:firmware/common.git > git --version # timeout=10 using GIT_SSH to set credentials Git Read-only key for Jenkins > git fetch --tags --progress git@gitlabee:firmware/common.git +refs/heads/*:refs/remotes/common/* > git config remote.common.url git@gitlabee:firmware/common.git # timeout=10 > git config --add remote.common.fetch +refs/heads/*:refs/remotes/common/* # timeout=10 > git config remote.common.url git@gitlabee:firmware/common.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from git@gitlabee:firmware/common.git using GIT_SSH to set credentials Git Read-only key for Jenkins > git fetch --tags --progress git@gitlabee:firmware/common.git +refs/heads/*:refs/remotes/common/* --prune > git rev-parse refs/remotes/common/release/v_1.6_rc2^{commit} # timeout=10 > git rev-parse refs/remotes/common/common/release/v_1.6_rc2^{commit} # timeout=10 > git rev-parse common/release/v_1.6_rc2^{commit} # timeout=10 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. Finished: FAILURE When running manually I can do: > git rev-parse release/v_1.6_rc2 8031a421b954a91fb7a74c7b78d76d6e578826b1 Perhaps there is an attribute I can add to the checkout command to make it look for tags, but it doesn't seem to be documented, and it doesn't show up in the pipeline syntax snippet generator.
            tomasbjerre Tomas Bjerre made changes -
            Assignee Tomas Bjerre [ tomasbjerre ]
            tomasbjerre Tomas Bjerre made changes -
            Assignee Tomas Bjerre [ tomasbjerre ] Mark Waite [ markewaite ]
            tomasbjerre Tomas Bjerre made changes -
            Assignee Mark Waite [ markewaite ]
            Hide
            plabedan Paul Labedan added a comment -

            I also don't think it's a duplicate of JENKINS-46207.

            What's needed here is a 'tag' or 'ref' parameter, like the 'branch' one.

            Show
            plabedan Paul Labedan added a comment - I also don't think it's a duplicate of JENKINS-46207 . What's needed here is a 'tag' or 'ref' parameter, like the 'branch' one.
            plabedan Paul Labedan made changes -
            Resolution Duplicate [ 3 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            allan_burdajewicz Allan BURDAJEWICZ added a comment -

            The git step is meant to be used for simple use cases. You can't for example specify a specific refspec. If you want to build tags, use the checkout step and specify the refspec +refs/tags/:refs/remotes/origin/tags/. For example:

            node {
                stage("testCheckout") {
                    checkout([$class: 'GitSCM', 
                        branches: [[name: 'refs/tags/mytag']], 
                        userRemoteConfigs: [[
                            credentialsId: 'myCredentialsId', 
                            refspec: '+refs/tags/*:refs/remotes/origin/tags/*', 
                            url: 'https://my.github.server/myuser/myrepo.git']]
                    ])
                }
            }
            
            Show
            allan_burdajewicz Allan BURDAJEWICZ added a comment - The git step is meant to be used for simple use cases. You can't for example specify a specific refspec . If you want to build tags, use the checkout step and specify the refspec +refs/tags/ :refs/remotes/origin/tags/ . For example: node { stage( "testCheckout" ) { checkout([$class: 'GitSCM' , branches: [[name: 'refs/tags/mytag' ]], userRemoteConfigs: [[ credentialsId: 'myCredentialsId' , refspec: '+refs/tags/*:refs/remotes/origin/tags/*' , url: 'https: //my.github.server/myuser/myrepo.git' ]] ]) } }
            Hide
            markewaite Mark Waite added a comment - - edited

            Allan BURDAJEWICZ described correctly why this is not a bug. The `git` step intentionally is a simple subset of the full capabilities of the `checkout` step. Use the `checkout` step

            Derrick Gibelyou you can find an example using the full checkout step to checkout a specific tag in the Jenkinsfile of my jenkins-bugs repository on the JENKINS-37050 branch.

            The default clone settings intentionally do not download tags so that less data is transferred for multi-branch pipelines that are building a single branch. The example file adds the CloneOption which downloads tags.

            Show
            markewaite Mark Waite added a comment - - edited Allan BURDAJEWICZ described correctly why this is not a bug. The `git` step intentionally is a simple subset of the full capabilities of the `checkout` step. Use the `checkout` step Derrick Gibelyou you can find an example using the full checkout step to checkout a specific tag in the Jenkinsfile of my jenkins-bugs repository on the JENKINS-37050 branch . The default clone settings intentionally do not download tags so that less data is transferred for multi-branch pipelines that are building a single branch. The example file adds the CloneOption which downloads tags.
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Not A Defect [ 7 ]
            Hide
            mtdeguzis Michael DeGuzis added a comment - - edited

            Sorry, but this is a bit silly that tags are not considered a "simple" use case here. Thousands of projects use a tag for releases. Making them use the GitSCM class to pull a tag is not ideal. The vast majority of our Git workflow uses releases, as do many, many projects. Creating a branch for a release is not the intended workflow of Git.

            Show
            mtdeguzis Michael DeGuzis added a comment - - edited Sorry, but this is a bit silly that tags are not considered a "simple" use case here. Thousands of projects use a tag for releases. Making them use the GitSCM class to pull a tag is not ideal. The vast majority of our Git workflow uses releases, as do many, many projects. Creating a branch for a release is not the intended workflow of Git.
            Hide
            torstenreinhard Torsten Reinhard added a comment -

            Michael DeGuzis I totally agree to what you said. Typically, DeployJobs need to checkout a specific tag and it would be very helpful in getting this done as simple as possible (means supported by git branch: "", credentials: "", url: "" )

            Show
            torstenreinhard Torsten Reinhard added a comment - Michael DeGuzis I totally agree to what you said. Typically, DeployJobs need to checkout a specific tag and it would be very helpful in getting this done as simple as possible (means supported by git branch: "", credentials: "", url: "" )

              People

              • Assignee:
                Unassigned
                Reporter:
                boumenot Christopher Boumenot
              • Votes:
                9 Vote for this issue
                Watchers:
                19 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: