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

Pipeline Job Cannot Checkout Git Tag

    XMLWordPrintable

Details

    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

            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 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
            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}"
                    }
            
            

             

            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}"         }  

            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.

            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.
            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 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.

            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']]
                    ])
                }
            }
            
            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' ]] ]) } }
            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

            derrickgw 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 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 derrickgw 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.
            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.

            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.

            mtdeguzis 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: "" )

            torstenreinhard Torsten Reinhard added a comment - mtdeguzis 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

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

              Dates

                Created:
                Updated:
                Resolved: