Question

问题

我在一个项目中有两个存储库A和B，每个存储库都有自己的管道A-CI和B-CI。该存储库是Azure Repos Git（因此不是外部存储库）。每当B-CI完成时，我就可以触发管道A-CI。如果A-CI是由对分支develop的提交触发的，则B-CI被触发以构建master，尽管B也具有develop分支。
当构建了B的新开发版本时，我想为开发环境构建A的新版本。

是否可以让管道资源触发B-CI管道来构建与由管道资源刚刚构建的分支同名的分支？如果在master中没有匹配的分支的情况下回退到B，对我来说很好。

但是，如果A-C和B-CI都引用相同存储库的不同管道Yaml，则此方案有效。

管道YAML

A-CI

trigger:
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: 'MyBuildPool'
    steps:
      - powershell: |
          Write-Host "Building A"

B-CI

resources:
  pipelines:
    - pipeline: Pipeline_A
      source: 'A-CI'
      trigger:
        branches:
          - master
          - develop
          - feature/*

trigger: 
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: MyBuildPool
    steps:
      - powershell: |
          Write-Host $(Build.SourceBranch) # is always refs/heads/master
          Write-Host $(Build.Reason) # is ResourceTrigger

背景信息

其背后的主要思想是，A包含IaC项目，只要该项目的基础结构发生变化，那么也应该部署所有应用程序。
我不想将IaC放入应用程序仓库中，因为我们有多个应用程序，因此我必须将IaC代码拆分为几个块。
然后，我可能仍然会遇到相同的问题，因为某些资源（例如Azure KeyVault）在应用程序之间共享，因此A仍将包括所有应用程序使用的通用内容，并且对其进行更改将需要重新部署所有资源。应用。

Answer 1

请检查pipeline triggers：

如果触发管道和被触发管道使用相同的存储库，则当一个管道触发另一个管道时，两个管道将使用相同的提交运行。如果您的第一个管道构建了代码，第二个管道对其进行了测试，这将很有帮助。

但是，如果两个管道使用不同的存储库，则触发的管道将使用其默认分支中的最新版本的代码。

在这种情况下，由于master是B-CI的默认分支，因此$(Build.SourceBranch)始终为refs/heads/master。

一种解决方法：

您可以为存储库B创建新的Yaml管道。您可以将yaml文件的类似内容用于B-CI。您只需要将其中的内容更改为：

resources:
  pipelines:
    - pipeline: Pipeline_A
      source: 'A-CI'
      trigger:
        branches:
          - develop

当我们创建新的yaml文件时，它总是放在master分支中。对我来说，我在dev分支中创建了一个同名文件，并在其中复制了相同的内容。然后我在master分支中删除了新的yaml文件，现在，当构建A-CI管道的dev时，将使用B repos的dev。

Answer 2

我认为我找到了一个很好的解决方法，因为内置的管道触发程序无法解决我们的特定问题（尽管我不能说我们是否有奇怪的方法并且有更好的方法）。

我现在正在做的是基于此Azure CLI DevOps extension使用docs entry并手动触发管道。

管道YAML

A-CI

trigger:
- '*'

stages:
- stage: Build
  displayName: Build something and create a pipeline artifact
  jobs:
  - job: BuildJob
    pool:
      name: 'MyBuildPool'
    steps:
      - powershell: |
          Write-Host "Building A"
      # steps to publish artifact omitted

- stage: TriggerAppPipelines
  displayName: Trigger App Pipeline
  jobs:
  - job: TriggerAppPipelinesJob
    displayName: Trigger App Pipeline
    steps:
    - bash: az extension list | grep azure-devops
      displayName: 'Ensure Azure CLI DevOps extension is installed'
    - bash: |
        echo ${AZURE_DEVOPS_CLI_PAT} | az devops login
        az devops configure --defaults organization=https://dev.azure.com/MyOrg project="MyProject" --use-git-aliases true
      displayName: 'Login Azure CLI'
      env:
        AZURE_DEVOPS_CLI_PAT: $(System.AccessToken)
    # By passing the build Id of this A-CI run, I can use that in B-CI to download the matching artifact of A-CI.
    # If there is no matching branch, then the command fails. 
    - bash: |
        az pipelines run --branch $(Build.SourceBranch) --name "B-CI" --variables a_Version="$(Build.BuildId)" -o none
      displayName: 'Trigger pipeline'

B-CI

trigger: 
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: MyBuildPool
    steps:
      - powershell: |
          Write-Host $(Build.SourceBranch) # is same as the the triggering A-CI branch
          Write-Host $(Build.Reason) # B-CI is triggered manually but the user is Project Collection Build Service, so automated runs can be distinguished

由于B-CI现在是手动触发的，因此不再需要资源节点。

我希望Azure管道可以像创建触发管道一样构建同名的分支

2 个答案: