Question

我有一个包含多个子项目（如果重要的话，可以使用Node / TypeScript）的mono-repo。我试图在Azure DevOps中设置相对简单的请求请求设置，该部署旨在部署PR环境进行测试。它由2个管道组成，我想在PR中一个接一个地触发。如果任何一个失败，PR也将失败。该代码托管在Azure DevOps Git中。

这是我要实现的步骤：

使用标签solution-a创建PR，以便从features/feature-x合并到dev分支
分支策略基于标签solution-a-pipeline触发solution-a。如果标签不同，则应触发其他管道。
solution-a-pipeline在infrastructure-pipeline分支*的上下文中依次触发solution-a-build-pipeline和features/feature-x。
如果solution-a-pipeline成功完成了（间接意味着infrastructure-pipeline和solution-a-build-pipeline也成功完成了），则认为辫子成功了。否则，它将失败并且PR无法完成。

*“在上下文中”是指用于每个管道的实际yaml文件是来自功能分支的文件。这是因为我希望它能够测试对管道的任何更改以及管道中的任何步骤。

有没有办法做到这一点？我已经尝试使用管道文件，模板，资源和触发器的不同组合达数天之久，但似乎无法全神贯注。

Answer 1

我设法解决了这个问题。它涉及几个步骤和一些硬编码，但是我现在能够使用某些定义的标签来标记一个“拉取请求”，并触发生成验证pipeline从而仅运行相关部分。

我的设置包括一个大的pr-pipeline.yml文件，该文件由对我的dev分支的PR的构建验证触发。触发器是手动的，但是是必需的，它允许发行PR的人员在开始之前对其进行相应的标记。

一旦管道运行，第一步便会使用Azure DevOps REST API通过调用此终结点来确定关联的PR上存在哪些标记：

https://dev.azure.com/$(organizationName)/$(System.TeamProjectId)/_apis/git/repositories/$(Build.Repository.ID)/pullRequests/$(System.PullRequest.PullRequestId)/labels?api-version=5.1-preview.1

predefined variables为管道提供了组织名称以外的所有必需参数。

要调用端点，我使用的是Azure DevOps在预定义变量System.AccessToken和一个小的PowerShell脚本中提供给代理的个人访问令牌（PAT）：

$accessToken = "$(System.AccessToken)"
$basicAuth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$accessToken"))
$headers = @{Authorization = "Basic $basicAuth"}
$url = $(url)
$data = Invoke-WebRequest -Method Get -Uri $url -Headers $headers
Write-Host "##vso[task.setvariable variable=prlabels]$data"

一旦有了标签，我就会使用一个小的PowerShell代码段将每个标签提取为一个单独的变量。 prlabels变量填充为：

$tagsJson = '$(prlabels)' | ConvertFrom-Json
$tags = $tagsJson.value | ForEach-Object { $_.name }
Write-Host "Tags: $($tags -join ";")"
$tags | ForEach-Object { Write-Host "##vso[task.setvariable variable=prlabel_$_;isOutput=true]true" }

如果我的pr被solution-a和solution-c标记，则将导致定义以下输出变量：

prlabel_solution-a = true
prlabel_solution-c = true

最后，我可以将这些输出变量用作触发相关作业的条件，这些作业执行相应解决方案的实际构建和部署。提取标签的作业称为PreReq，而输出各个变量的任务称为prlabels：

- job: DeploySolutionA
  dependsOn: PreReq
  condition: and(succeeded(), eq(dependencies.PreReq.outputs['prlabels.prlabel_solution-a'], 'true'))
  # ...

所有这些共同使我能够根据用户定义在PR中部署一个或多个特定解决方案。仍然需要用户知道这些标签，但是至少它们不必在PR之外的每次运行中手动启动每个管道。

Answer 2

用于单仓库的PR的Azure DevOps管道结构

我可以理解您的请求，但是AFAI for Azure开发人员，我不认为目前有这种方法可以满足您的需求。

这里有三个挑战：

我们无法在标签请求中添加标签，您可以查看this thread了解详情。
我们无法基于标签触发不同的构建管道。选项构建验证没有这种条件。
我们无法设置构建验证的顺序。我们可以在构建验证中设置多个构建管道，但是无法设置它们的顺序。如果我们添加构建验证并使用构建完成设置构建顺序，但是构建验证将仅验证添加的构建管道的结果，而不验证其他关联管道的结果

总而言之，我不认为目前有这种方法可以满足您的需求。

希望这会有所帮助。

单仓库中的PR的Azure DevOps管道结构

2 个答案: