azure-pipelines.yml 中的多个单独触发器 [英] Multiple separate triggers in azure-pipelines.yml

问题描述

我目前有一个在子目录中包含服务的 monorepo，我倾向于将其转变为带有 metarepo 的 multirepo.

I currently have a monorepo with services in subdirectories that I'm leaning towards turning into a multirepo with a metarepo.

我决定尝试 Azure DevOps 的一个原因是有人告诉我您可以在子目录上设置触发器，例如:

One of the reasons I decided to give Azure DevOps a try was someone told me you can have triggers on the subdirectories like:

trigger:
  branches:
    include:
    - master
  paths:
    include:
    - client

经过测试，有效.

然而，我想知道是否有可能有多个独立的触发器，或者这是否需要一个 polyrepo 或多个 .yml?原因是如果只有 client 服务有变化，它只会触发那组测试、构建和部署，而不触发 api 服务运行测试，构建和部署.

However, what I'm wondering is if it possible to have multiple independent triggers, or does this require either a polyrepo or multiple .yml? The reason being if there are only changes in the client service, it only triggers that set of tests, build, and deployment, while not triggering the api service to run tests, build, and deploy.

例如:

trigger:
  branches:
    include:
    - master
  paths:
    include:
    - client

  stages:
    ...
    Run tests
    If tests pass, build and push to ACR
    Deploy to AKS
    ...

trigger:
  branches:
    include:
    - master
  paths:
    include:
    - api

  stages:
    ...
    Run tests
    If tests pass, build and push to ACR
    Deploy to AKS
    ...

这样，一个更改不会导致整个应用程序被重建，只会导致更改的部分.

That way, changes in one doesn't cause the entire application to be rebuilt, just what changed.

但是，这是否需要多个 .yml 文件(甚至不确定是否可以识别 azure-pipelines.yml 以外的任何文件)，这是否需要 polyrepo，或者这在我没有看到的单个 azure-pipelines.yml 中可行吗?

However, does this require multiple .yml files (not even sure if anything other than azure-pipelines.yml is recognized), does this necessitate a polyrepo, or is this doable in a single azure-pipelines.yml that I'm just not seeing?

推荐答案

如果我正确理解您的要求.您可以在单个 azure-pipeline.yml 中实现此目的.请检查下面的示例 yml.

If i understand your request correctly. You can achieve this in a single azure-pipeline.yml. Please check below example yml.

trigger:
  branches:
    include:
    - master
  paths:
    include:
    - client/*
    - api/*

jobs:
- job: getchangepath
  pool:
    vmImage: 'windows-latest'
  steps: 
  - powershell: |
      $url="$(System.CollectionUri)/$(System.TeamProject)/_apis/git/repositories/$(Build.Repository.ID)/commits/$(Build.SourceVersion)/changes?api-version=5.1"
      $result = Invoke-RestMethod -Uri $url -Headers @{Authorization = "Bearer $(System.AccessToken)"} -Method GET
                       
      $changesFolder = $result.changes | Where-Object{$_.item.gitObjectType -match "tree"} | Select-Object -Property {$_.item.path}
     
      foreach($path in $changesFolder){
        if($path -match '/client'){
          echo "##vso[task.setvariable variable=Client;isOutput=true]$True"
          break
        }
      }

      foreach($path in $changesFolder){
        if($path -match '/api'){
          echo "##vso[task.setvariable variable=Api;isOutput=true]$True"
          break
        }
      }
    name: MyVariable

- job: client
  pool :
    vmImage: 'windows-latest'
  dependsOn: getchangepath
  condition: eq(dependencies.getchangepath.outputs['Myvariable.Client'], 'true')
  steps:
  - powershell: echo 'client job start'
  
- job: api
  pool :
    vmImage: 'windows-latest'
  dependsOn: getchangepath
  condition: eq(dependencies.getchangepath.outputs['Myvariable.Api'], 'true')
  steps:
  - powershell: echo 'api job start'

在yml上面.我有三份工作.在第一个工作 getchangepath 中，我调用了 git get changes 在 powershell 任务中使用 rest api 以获取触发构建的更改路径.还有 如果路径包含路径/client 或/api，则输出变量.

In above yml. I have three jobs. In the first job getchangepath I call git get changes rest api in the powershell task to get the changed path which triggers the build. And output the variables if the path contains path /client or /api.

Job client 和 job api 依赖于 job getchangepath 并且将在 job 中的输出变量的条件下执行获取更改路径.

Job client and job api are depend on job getchangepath and will be executed on the condition of the output variable in job getchangepath.

假设我更改了文件夹客户端中的一个文件并将更改提交到 azure 存储库.然后在作业 getchangepath 完成后.MyVariable.Client 将设置为 true.然后作业客户端将评估其状况并开始使用.作业 Api 将无法满足其条件并被跳过.

Suppose I changed a file in folder client and commit the change to azure repo. Then after job getchangepath is finished. MyVariable.Client will be set to true. Then Job client will evaluate its condition and get started. Job Api will fail its condition and get skipped.

这篇关于azure-pipelines.yml 中的多个单独触发器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！