基于子文件夹的更改触发Azure DevOps构建 [英] Triggering Azure DevOps builds based on changes to sub folders

查看:100
本文介绍了基于子文件夹的更改触发Azure DevOps构建的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have a Visual Studio solution with multiple projects, each project is an individual microservice. It is very convenient to the development team to have all the services in the same solution, and git repo, as services can call each other.

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

但是,我想在Azure DevOps发生更改时独立构建/发布单个微服务,因此,如果ServiceA是唯一要更改的服务,则ServiceA是唯一构建和部署的服务.

I would, however, like to independently build/release the individual microservices in Azure DevOps when they change, so if ServiceA is the only service to change, then ServiceA is the only service built and deployed.

为此,我创建了一个新的构建管道定义,其中设置了路径过滤器",以在微服务文件夹的内容发生更改时触发构建(因此,每个微服务都添加了一个路径过滤器以进行监视).

To this end I created a new build pipeline definition with "Path filters" set to trigger the build when the contents of a microservice folder change (so one path filter added per microservice to monitor).

我的问题是,当触发构建时(例如,基于对SubFolderA的更改),我无法告诉构建定义仅在SubFolderA中构建.sln文件.

My problem here is that when a build is triggered (based on a change to SubFolderA e.g.) I have no way to tell the build definition to only build the .sln file in SubFolderA.

我可以为每个微服务创建一个单独的构建定义,并在单独的子文件夹上触发每个构建,但这会产生很大的开销,即我将需要维护15个单独的构建定义(对于我构建的每个分支也是如此),并且现在,自托管构建代理上所需的存储将为NumberOfService x NumberOfBranchesBeingBuild x SizeOfRepo.

I could create a separate build definition for each microservice and trigger each build on separate subfolders, but this would come at significant overhead, i.e. I would need to maintain 15 separate build definitions (same again for each branch I build), and the storage required on our self host build agent would now be NumberOfService x NumberOfBranchesBeingBuild x SizeOfRepo.

有没有一种方法可以使用带有git路径过滤器"和多个路径的单个构建定义,这反过来又启动了多个构建实例,并将触发构建的路径的值输入到构建定义中,因此告诉构建实例要构建哪个.sln文件?

Is there a way to use a single Build Definition with git "Path filters" and multiple paths defined, which in turn kicks off multiple build instances and feeds the value of the path that triggered the build into the build definition and so telling the build instance which .sln file to build?

我希望这是有道理的!

推荐答案

您可以在下面进行操作

  1. 根据您的微服务创建变量,其值为"False"

例如,MicroserviceAUpdated =假",MicroserviceBUpdated =假"等,

E.g,MicroserviceAUpdated= "False",MicroserviceBUpdated= "False" etc.,

  1. 在构建定义的开头添加Powershell脚本任务. Powershell脚本将执行以下操作:
  1. Add a Powershell script task at the begin of your build definition. The powershell script will do the following:

在构建中获取更改集/提交,以检查哪些文件已更改.

Get the changeset/commit in the build to check which files are changed.

  • 仅将MicroserviceAUpdated变量更新为"true" 文件在SubFolderA下更改.
  • 仅将MicroserviceBUpdated变量更新为"true"
    文件在SubFolderA下更改.
  • Update the MicroserviceAUpdated variable to "true" if only any files are changed under SubFolderA.
  • Update the MicroserviceBUpdated variable to "true" if only any
    files are changed under SubFolderA.

等等.

  1. 为每个微服务创建单独的构建任务,将构建任务配置为在如下所示的自定义条件下运行

对于MicroserviceA构建任务

自定义条件": and(succeeded(), eq(variables['MicroserviceAUpdated'], 'True'))

"Custom conditions": and(succeeded(), eq(variables['MicroserviceAUpdated'], 'True'))

对于MicroserviceB构建任务

自定义条件": and(succeeded(), eq(variables['MicroserviceBUpdated'], 'True'))

"Custom conditions": and(succeeded(), eq(variables['MicroserviceBUpdated'], 'True'))

等等...

如果变量的值为False

对于步骤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"
    }
}

这篇关于基于子文件夹的更改触发Azure DevOps构建的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆