Jenkins： GitSCM在分离的头状态下完成克隆，我如何确保检查出正确的分支名称？

Question

我写了一个Jenkins管道，它克隆一个git存储库并运行一个MSBUILD构建。

我使用GitSCM将存储库克隆到工作区中，如下所示：

stage ('Checkout SCM & Merge master to feature branch') {
    checkout([$class: 'GitSCM', branches: [[name: '*/feature/*']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '99f978af-XXXX-XXXX-8147-2cf8f69ef864', url: 'http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME']]])
}

克隆回购协议的步骤完成后，HEAD指向一个分离的HEAD，我不明白为什么。

Started by user itai ganot
[Pipeline] node
Running on master in C:\Program Files (x86)\Jenkins\workspace\bbb
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Setup)
[Pipeline] deleteDir
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Checkout SCM & Merge master to feature branch)
[Pipeline] checkout
Cloning the remote Git repository
Cloning repository http://pctfs1:8080/tfs/DefaultCollection/PC_International/_git/Ensure-pcs-intl
 > git.exe init C:\Program Files (x86)\Jenkins\workspace\bbb # timeout=10
Fetching upstream changes from http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/Ensure-pcs-intl
 > git.exe --version # timeout=10
using GIT_SSH to set credentials javab SSH file
 > git.exe fetch --tags --progress http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME +refs/heads/*:refs/remotes/origin/*
 > git.exe config remote.origin.url http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME # timeout=10
 > git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git.exe config remote.origin.url http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME # timeout=10
Fetching upstream changes from http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME
using GIT_SSH to set credentials javab SSH file
 > git.exe fetch --tags --progress http://TFS_SERVER:8080/tfs/DefaultCollection/PC_International/_git/REPO_NAME +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/feature/merge_tfs
Seen branch in repository origin/master
Seen branch in repository origin/origin
Seen 3 remote branches
 > git.exe tag -l # timeout=10
Checking out Revision 97b3493db4f726e11e334e5ba34fa808b63edec5 (origin/feature/merge_tfs)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 97b3493db4f726e11e334e5ba34fa808b63edec5
First time build. Skipping changelog.
[Pipeline] bat
[bbb] Running batch script

C:\Program Files (x86)\Jenkins\workspace\bbb>cd C:\Program Files (x86)\Jenkins\workspace\bbb 

C:\Program Files (x86)\Jenkins\workspace\bbb>git branch 
* (HEAD detached at 97b3493)

除此之外，众所周知，当运行詹金斯管道时，git参数没有正确评估，因此我不能通过简单地运行来修复它：

git checkout ${BRANCH_NAME}

那么，在开始MSBUILD步骤之前，如何确保HEAD指向分支名称呢？

我相信已经有人遇到了这种情况，并找到了解决办法。

Answer 1

如果您想使用管道配置实现相同的行为，请使用管道-

我的管道快照

Answer 2

添加[$class:'LocalBranch'，LocalBranch:***']修复了我的问题。

使用GitSCMplugin，成功签出主分支后。git/refs/heads/master仍然缺失，导致某些操作总是失败（例如，git log——装饰…以创建变更日志）。

Answer 3

经过大量的研究，甚至联系詹金斯的专业人士，以及我这边的多次尝试，我找到了如何解决这个问题。

以下代码修复了该问题：

checkout([$class: 'GitSCM', branches: [[name: '*/feature/*']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'LocalBranch', localBranch: "**"]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '99f978af-XXXX-XXXX-8147-2cf8f69ef864', url: 'http://TFS_SERVER:8080/tfs/DefaultCollection/Product/_git/Project']]])

注意"**"在local分支扩展中。

詹金斯日志：

Checking out Revision 97b3493db4f726e11e33XXXba34fa808b63edec5 (origin/feature/merge_tfs)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 97b3493db4f726e11e33XXXba34fa808b63edec5
 > git.exe branch -a -v --no-abbrev # timeout=10
 > git.exe checkout -b feature/merge_tfs 97b3493db4f726e11e33XXXba34fa808b63edec5
 > git.exe rev-list 97b3493db4f726e11e334e5ba34fa808b63edec5 # timeout=10
[Pipeline] bat
[Ensure] Running batch script

C:\Program Files (x86)\Jenkins\workspace\Ensure>cd C:\Program Files (x86)\Jenkins\workspace\Ensure 

C:\Program Files (x86)\Jenkins\workspace\Ensure>git branch 
* feature/merge_tfs