Azure DevOps流水线阶段间仓库变更无法实时检出问题咨询

这是正常行为吗？ #

是正常的。Azure DevOps流水线默认以触发流水线时的仓库提交版本作为整个流水线的执行基准，所有阶段的默认检出操作都会拉取这个初始版本，不会自动同步后续阶段推送到仓库的新变更。所以阶段2、3默认看不到阶段1推送的内容，必须重新运行流水线才能基于新的版本执行。

是缓存导致的吗？ #

不是缓存问题，核心是流水线的版本锁定逻辑——整个流水线的上下文绑定到触发时的版本，每个阶段的checkout任务默认复用这个版本，而非实时拉取仓库最新状态。

如何修改该行为？ #

要让后续阶段能获取前面阶段推送的变更，需要在阶段2、3的检出步骤中强制拉取仓库最新版本，具体有两种实现方式：

方式1：配置checkout任务拉取最新版本 #

在阶段2和阶段3的步骤中，修改检出任务的配置，指定拉取最新代码并保留凭据：

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
    - checkout: self
      fetchDepth: 0          # 拉取完整仓库历史
      persistCredentials: true  # 保留仓库凭据，用于拉取最新变更
      clean: true            # 清理工作区，确保无残留旧文件
    # 后续创建文件并推送的步骤...

- stage: Stage3
  jobs:
  - job: Job3
    steps:
    - checkout: self
      fetchDepth: 0
      persistCredentials: true
      clean: true
    # 后续读取文件的步骤...

方式2：检出后执行git pull命令 #

如果不想修改checkout任务的默认配置，可以在检出后添加一个脚本步骤，手动拉取最新分支的变更：

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
    - checkout: self
      persistCredentials: true  # 必须保留凭据才能拉取
    - script: |
        git pull origin $(Build.SourceBranchName)
      displayName: '拉取最新代码'
    # 后续创建文件并推送的步骤...

额外注意事项 #

• persistCredentials: true是关键配置，它会让流水线的工作区保留仓库的访问凭据，确保能成功拉取最新变更。
• 如果场景允许，更推荐的做法是拆分流水线：阶段1推送变更后，触发一个新的流水线运行后续阶段，这样新流水线会基于最新的仓库版本执行，避免同步问题。

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