如何在Azure DevOps Pipeline中识别构建期间变更的文件？（发布产物覆盖共享目录场景咨询）

我来分享几个针对你这个场景的可行方案，都是在Azure DevOps Pipeline里能落地的，完美避开Artifact覆盖共享目录导致没法对比的问题：

1. 直接从Git历史获取变更文件（最推荐） #

既然目录对比走不通，那直接从Git的提交记录里捞变更文件是最可靠的——毕竟Git本身就是为跟踪文件变更设计的。你可以通过Azure DevOps的内置变量+Git命令实现：

步骤： #

• 第一步：获取上一次成功构建的提交ID
  如果你的Pipeline是针对同分支运行的，可以用Azure DevOps REST API拿到最近一次成功构建的提交版本。比如在PowerShell任务里执行：

  $apiUrl = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/build/builds?definitions=$(System.DefinitionId)&statusFilter=succeeded&top=1&branchName=$(Build.SourceBranch)&api-version=7.1-preview.7"
  $lastBuild = Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization = "Bearer $(System.AccessToken)"}
  $lastCommitId = $lastBuild.value[0].sourceVersion
  

  注意要给Pipeline的服务账号分配Build读取权限，否则API会返回403。

• 第二步：对比提交获取变更文件
  用git diff命令对比当前提交和上一次成功构建的提交，输出变更文件列表：

  git diff --name-only $lastCommitId $(Build.SourceVersion) > changed-files.txt
  

  这个changed-files.txt里就包含了本次构建相对于上一次成功构建的所有变更文件，完全不依赖目录对比，自然避开了Artifact覆盖的问题。

2. 单独发布变更文件为独立Artifact #

如果你需要把变更文件用于后续发布流程，可以把它们单独打包成一个Artifact，和全量Artifact分开存储，这样就不会覆盖共享目录的内容：

步骤： #

• 先按上面的方法生成changed-files.txt
• 添加CopyFiles任务，设置Contents为@changed-files.txt（注意如果是Windows路径，要确保文件里的路径格式正确），把变更文件复制到一个单独的目录（比如$(Build.ArtifactStagingDirectory)/changed-files）
• 添加PublishBuildArtifacts任务，把这个目录发布成名为ChangedFiles的Artifact
  后续发布时，你只需要下载这个ChangedFilesArtifact，就能拿到本次的变更文件，完全不会影响共享目录里的全量内容。

3. 用变量组跟踪上次构建的基准状态 #

如果不想调用REST API，你可以把每次成功构建的基准信息（比如提交ID）存在Azure DevOps的变量组里，下次构建直接读取对比：

步骤： #

• 先创建一个变量组（比如BuildBenchmark），添加一个变量LastSuccessfulCommit，初始值可以设为项目的初始提交ID
• 构建开始时，读取这个变量的值：$lastCommitId = $(LastSuccessfulCommit)
• 用Git diff对比当前提交和$lastCommitId，得到变更文件
• 构建成功后，用PowerShell脚本更新变量组里的LastSuccessfulCommit为当前的Build.SourceVersion：

  $apiUrl = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/distributedtask/variablegroups/{变量组ID}?api-version=7.1-preview.2"
  $body = @{
      variables = @{
          LastSuccessfulCommit = @{
              value = "$(Build.SourceVersion)"
          }
      }
  } | ConvertTo-Json
  Invoke-RestMethod -Uri $apiUrl -Method Put -Headers @{Authorization = "Bearer $(System.AccessToken)"} -Body $body -ContentType "application/json"
  

  这个方法适合简单场景，不需要额外的存储，直接用Azure DevOps原生的变量组就能维护基准。

额外注意事项 #

• 如果你的Pipeline支持跨分支构建，要在获取上一次构建时加上分支过滤（就像第一个方案里的branchName=$(Build.SourceBranch)参数），避免拿到其他分支的构建记录
• 如果遇到合并提交，git diff可能会包含更多文件，你可以用git diff --name-only $lastCommitId $(Build.SourceVersion) --diff-filter=ACMRT来只筛选新增、修改、重命名等类型的变更文件
• 所有涉及REST API的操作，都要确保Pipeline的服务账号有足够的权限（比如变量组的编辑权限、构建的读取权限）

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