根据子文件夹的更改触发Azure DevOps构建

Question

我有一个包含多个项目的Visual Studio解决方案，每个项目都是一个单独的微服务。开发团队在同一个解决方案和git repo中拥有所有服务非常方便，因为服务可以相互调用。

Master.sln - SubFolderA - MicroserviceA.sln
           - SubFolderB - MicroserviceB.sln
           - SubFolderC - MicroserviceC.sln

但是，我希望在Azure DevOps发生变化时独立构建/发布各个微服务，因此如果ServiceA是唯一需要更改的服务，那么ServiceA是唯一构建和部署的服务。

为此，我创建了一个新的构建管道定义，其中“路径过滤器”设置为在微服务文件夹的内容发生更改时触发构建（因此每个微服务添加一个路径过滤器进行监视）。

我的问题是，当触发构建时（基于对SubFolderA的更改），我无法告诉构建定义只在SubFolderA中构建.sln文件。

我可以为每个微服务创建一个单独的构建定义，并在单独的子文件夹上触发每个构建，但这会产生很大的开销，即我需要维护15个单独的构建定义（对于我构建的每个分支都是相同的），并且需要存储我们的自我主机构建代理现在将是NumberOfService x NumberOfBranchesBeingBuild x SizeOfRepo。

有没有办法使用单个构建定义与git“路径过滤器”和多个路径定义，这反过来启动多个构建实例，并将触发构建的路径的值提供给构建定义，从而告诉构建实例哪个.sln文件要构建？

我希望这是有道理的！

Answer 1

你可以在下面这样做

1. 根据您的微服务创建变量，值为“False”

例如，MicroserviceAUpdated =“False”，MicroserviceBUpdated =“False”等，

2. 在构建定义的开头添加Powershell脚本任务。 powershell脚本将执行以下操作：

获取构建中的变更集/提交以检查哪些文件已更改。

• 如果在MicroserviceAUpdated下只更改了任何文件，请将SubFolderA变量更新为“true”。
• 如果只有任何变量，请将MicroserviceBUpdated变量更新为“true” 文件在SubFolderA下更改。

等......

3. 为每个微服务创建单独的构建任务，配置构建任务以使用下面的自定义条件运行

对于MicroserviceA构建任务

“自定义条件”：and(succeeded(), eq(variables['MicroserviceAUpdated'], 'True'))

对于MicroserviceB构建任务

“自定义条件”：and(succeeded(), eq(variables['MicroserviceBUpdated'], 'True'))

所以......

这样，如果变量的值为False，则将跳过MicoserviceTask

对于第2步

$files=$(git diff HEAD HEAD~ --name-only)
$temp=$files -split ' '
$count=$temp.Length
echo "Total changed $count files"
For ($i=0; $i -lt $temp.Length; $i++)
{
  $name=$temp[$i]
  echo "this is $name file"
  if ($name -like "SubFolderA/*")
    {
      Write-Host "##vso[task.setvariable variable=MicroserviceAUpdated]True"
    }
}

Answer 2

Jayendran的回答非常好！这是执行第2步的PowerShell-y方式：

$editedFiles = git diff HEAD HEAD~ --name-only
$editedFiles | ForEach-Object {
    Switch -Wildcard ($_ ) {
        'SubFolderA/*' { Write-Output "##vso[task.setvariable variable=MicroserviceA]True" }
        # The rest of your path filters
    }
}

Answer 3

在“触发器”选项卡上，有一个选项可指定要构建的项目的路径。指定该路径时，只有包含与包含/排除规则匹配的修改的提交才会触发构建。

就我而言，这是一个比PowerShell脚本更好的解决方案，PowerShell脚本仍会触发所有项目的构建和发布，这些项目会对我们的Slack发送垃圾邮件并填补我们项目历史的垃圾。