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

问题描述

我目前有一个在子目录中提供服务的monorepo，我倾向于将其与metarepo转换为multirepo.

我决定尝试使用Azure DevOps的原因之一是有人告诉我您可以在以下子目录上使用触发器:

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

经过测试，可以正常工作.

但是，我想知道的是是否可能有多个独立的触发器，或者这需要一个polyrepo还是多个.yml?原因是，如果client服务仅发生更改，它只会触发该组测试，构建和部署，而不会触发api服务来运行测试，构建和部署.

例如:

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
    ...

那样，更改其中一个并不会导致整个应用程序都得到重建，而只是重建了什么.

但是，这是否需要多个.yml文件(甚至不确定是否可以识别除azure-pipelines.yml之外的任何其他文件)，这是否需要一个polyrepo，或者是否可以在单个azure-pipelines.yml中执行，我只是不这样做看到吗?

解决方案

如果我正确理解您的要求.您可以在单个azure-pipeline.yml中实现此目的.请检查以下示例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中，我呼叫/client或/api，则输出变量.

作业客户端和作业 api 取决于作业 getchangepath ，并且将根据作业中的输出变量来执行getchangepath .

假设我在文件夹客户端中更改了一个文件，并将更改提交给azure repo.然后，在作业getchangepath完成之后. MyVariable.Client将设置为true.然后，工作客户端将评估其状况并开始使用. Job Api将无法达到条件并被跳过.

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

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

Tested and it works.

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.

For example:

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.

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?

解决方案

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'

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 and job api are depend on job getchangepath and will be executed on the condition of the output variable in job getchangepath.

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屋！