Brad M added a comment - 2016-08-29 04:56 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

Pierre Monsimier added a comment - 2017-08-07 16:54 - 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}"         }  

Derrick Gibelyou added a comment - 2017-11-18 17:17 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.

Paul Labedan added a comment - 2018-03-28 10:08 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.

Allan BURDAJEWICZ added a comment - 2018-04-29 23:06 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' ]] ]) } }

Mark Waite added a comment - 2018-04-30 20:39 - 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.

Michael DeGuzis added a comment - 2018-08-08 13:00 - 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.

Torsten Reinhard added a comment - 2018-10-30 14:20 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: "" )