Azure DevOps同项目多仓库递归拉取子模块且不绕过保护的方法

1. 检查流水线服务主体的仓库权限 #

• 打开Azure DevOps项目的「项目设置」→「仓库」，找到所有涉及的仓库：my-repo、my-app、my-service-a、my-service-b、my-lib
• 找到流水线使用的服务主体（一般是「Project Collection Build Service (你的组织名)」，如果用了自定义服务连接就找对应的主体），确认它在每个仓库的权限列表里，并且拥有读取权限
• 如果仓库开了分支保护，得把这个服务主体加到允许拉取分支的用户/组里，不然就算有仓库权限也拉不了受保护的分支

2. 统一.gitmodules的URL格式 #

• 别混合用相对路径和完整URL，同一项目下推荐用HTTPS相对路径或者SSH URL：
  • HTTPS相对路径示例：url = ../my-app（前提是父仓库和子模块在同一项目下）
  • SSH URL示例：git@ssh.dev.azure.com:v3/你的组织名/你的项目名/my-app
• 逐个检查所有子模块的URL，确保拼写没出错，仓库名称完全匹配

3. 正确配置流水线Checkout步骤 #

• YAML流水线里，Checkout步骤必须同时开启submodules: true和persistCredentials: true，还要确保流水线权限里允许访问所有相关仓库：

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

• 要是用的经典流水线，在「获取源代码」步骤里，勾选「递归拉取子模块」和「允许脚本访问OAuth令牌」，这俩选项缺一不可

4. 验证子模块的分支/提交引用 #

• 本地运行git submodule status，检查每个子模块对应的提交ID是否存在于远程仓库，而且这个提交所在的分支是你有权限拉取的
• 如果子模块引用的是私有标签或者不存在的提交，也会触发权限错误，得把引用改成有效的分支或公开提交

5. 用多仓库检出替代子模块（可选） #

• 要是子模块的权限问题实在绕不开，可以直接在流水线里加多个Checkout步骤，分别拉取每个仓库到指定目录：

  steps:
  - checkout: self
    path: s/my-repo
  - checkout: git://你的项目名/my-app
    path: s/my-app
  - checkout: git://你的项目名/my-service-a
    path: s/my-service-a
  - checkout: git://你的项目名/my-service-b
    path: s/my-service-b
  - checkout: git://你的项目名/my-lib
    path: s/my-lib
  

• 这种方式不需要依赖子模块的凭证传递，直接用流水线的服务主体拉取每个仓库，权限配置更直观

内容的提问来源于stack exchange，提问作者Archimedes Trajano