Question

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

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

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和

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

Answer 1

设置git子模块的相对路径后，它可以工作

url= ../foo-dev-common

代替

url=https://MY_ORG@dev.azure.com/MY_ORG/PInC/_git/foo-dev-common

Answer 2

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

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

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管道变量的引用。）

上面的代码将完成主存储库的完整（“不浅表”）检出（例如对GitVersion有用），而没有子模块，而所有子模块也将进行浅检出。

编辑：获取授权标头的documented方法是

    $header = "AUTHORIZATION: bearer $(System.AccessToken)"

使用托管代理的管道上的Git子模块更新

2 个答案: