使用托管代理的管道上的Git子模块更新 [英] Git Submodule update on pipelines with hosted agent

查看:136
本文介绍了使用托管代理的管道上的Git子模块更新的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个自托管代理,并且有一个带有子模块的git存储库. .gitmodules中的URL为http://

I have a self hosted agent and have a git repository with submodules. URLs in .gitmodules are http://

当我尝试初始化作业时,它无法更新子模块.

When I try to initialize a job it fails to update submodules.

git submodule sync
git submodule update --init --force
Cloning into 'foo-dev-common'...
Submodule 'foo-dev-common' (https://MY_ORG@dev.azure.com/MY_ORG/PInC/_git/foo-dev-common) registered for path 'foo-dev-common'
fatal: could not read Password for 'https://MY_ORG@dev.azure.com': terminal prompts disabled
fatal: clone of 'https://MY_ORG@dev.azure.com/MY_ORG/PInC/_git/foo-dev-common' into submodule path 'foo-dev-common' failed
##[error]Git submodule update failed with exit code: 128
Finishing: Checkout foo-rose-identity-service@submod_bd_mahesh to s/foo-rose-identity-service

我也尝试添加存储库self和

I have also tried adding repository self and

    steps:
  - checkout: self
    submodules: true
    persistCredentials: true

推荐答案

forvaidya的答案对我不起作用(尽管现在已经4年了). (.gitmodules中的相对URL由git submodule sync解析为.git/config中的完整URL.)

forvaidya's answer didn't work for me (though it is now 4 years later). (Relative URLs in .gitmodules are resolved to full URLs in .git/config by git submodule sync.)

persistCredentials: true将保持授权标头在git config中可用,以用于将来的步骤,但是它由您的主存储库URL键入密钥.只要子模块存储库位于同一组织中,就可以重复使用标头,例如-在管道Powershell脚本中:

persistCredentials: true will keep the authorization header available in git config for future steps, but it is keyed by your main repo URL. As long as the submodule repo(s) are in the same organization, you can reuse the header, though - e.g. in a pipeline Powershell script:

steps:
- checkout: self
  submodules: false
  persistCredentials : true

- powershell: |
    $header = $(git config --get-all http.$(Build.Repository.Uri).extraheader)
    git -c http.extraheader="$header" submodule sync
    git -c http.extraheader="$header" submodule update --init --force --depth=1

(我从标准checkout步骤的日志中收集了这些详细信息.请注意对Build.Repository.Uri管道变量的引用.)

(I gleaned these details from the logs of the standard checkout step. Note the reference to the Build.Repository.Uri pipeline variable.)

以上内容将完成主存储库的完整(不浅表")检出(例如用于 GitVersion ),没有子模块,并且对所有子模块进行了浅层检出.

The above will accomplish a full ("unshallow") checkout of the main repo (useful for e.g. GitVersion), without submodules, and a shallow checkout of any submodules.

查看全文

登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆