Azure DevOps 管道 - 仅在另一个管道上触发,不提交

vip*_*pes 6 build-triggers azure-devops azure-pipelines

要求

因此,Azure DevOps 中有一些新功能允许管道触发其他管道,并在此处记录:https : //docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure- devops&tabs=yaml#pipeline-triggers-1听起来不错,除了我无法获得所需的行为。我想在同一个存储库中有 2 个管道:

  • 管道 A:仅由它自己的 repo 之外的多个其他管道触发,但在同一个项目中。作为被触发的结果,它对自己的回购进行了更改,因此触发了管道 B。
  • 管道 B:仅由对其自己的 repo 的更改触发,并且在触发时继续执行它需要做的任何事情

管道 A 语法

resources:
    pipelines:
    - pipeline: database
      source: database
      trigger:
        branches:
        - develop
        - release/*
        # The stages filter should work, according to: https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml
        # However, this error occurs when specifying: /azure-pipelines.yml (Line: 8, Col: 15): Stage filters in pipeline resource database is not supported.
        #stages:
        #- Build
    - pipeline: auth
      source: auth
      trigger:
        branches:
        - develop
        - release/*
    - pipeline: api
      source: api
      trigger:
        branches:
        - develop
        - release/*
    - pipeline: web
      source: web
      trigger:
        branches:
        - develop
        - release/*
  ... multiple triggers - 9 in total
stages:
  ...
Run Code Online (Sandbox Code Playgroud)

当前行为

管道 A 不会被任何其他管道触发,而只会在对其自己的 repo 进行更改时触发。由于它无论如何都会更改自己的存储库,因此它会在无限循环中触发自身。

问题/评论

  • 管道 A 的语法是否正确?
  • 来自文档:“但是,如果两个管道使用不同的存储库,则触发的管道将使用其默认分支中最新版本的代码。” 我假设这意味着来自默认分支的 yaml 管道将被激活。我们真的有那么一点控制吗?在管道声明中指定目标分支会好得多。
  • 是否有可能以某种方式获得触发管道的源分支?
  • 为什么阶段过滤器不按文档工作?
  • 在管道 A 中,为了停止循环,我尝试使用 $(Build.TriggeredBy.DefinitionId) 检查它是否与 $(System.DefinitionId) 相同,如果是,则跳过构建步骤,但是 $(Build.TriggeredBy.DefinitionId) ) 没有价值
  • 如果我不能让它工作,我倾向于让其他管道触发管道 A。

发现

  • 添加trigger: none到管道 A 的顶部会阻止它在对其 repo 进行提交时运行,它目前根本不运行!
  • 在一个单独帐户的简化管道场景中,我设法使触发构建工作,在同一个 repo 中有 2 个管道,并发现:
    • 执行的 yaml 管道文件与触发管道上的提交位于同一分支上
    • 检出的代码也来自与触发管道上的提交相同的分支
    • 从 GUI 手动执行管道不会触发相关管道
    • 依赖管道在第一次启动时立即触发并排队
    • 我无法使分支排除工作:无论排除条款如何,管道都会触发
  • 在单独的帐户中运行简化的管道场景,在 repo C 中使用管道 A,在 repo D 中使用依赖管道 B(同一个项目),到目前为止,我无法让管道 A 触发管道 B(我的原始场景)
  • 哦,太高兴了 :-) 有一个 azure devops 命令行扩展,它获得了管道支持并允许您触发管道:

vip*_*pes 10

工作解决方案

因为我的所有构建都集中在一个管道模板中,所以我更改了这个模板以在成功发布工件时触发我的管道 A。这是管道触发代码,它几乎逐字来自(https://docs.microsoft.com/en-us/azure/devops/cli/azure-devops-cli-in-yaml?view=azure-devops),除了从最后几个步骤:

# Updating the python version available on the linux agent
    - task: UsePythonVersion@0
      displayName: Upgrade build agent Python version
      inputs:
        versionSpec: '3.x'
        architecture: 'x64'

    # Updating pip to latest
    - script: python -m pip install --upgrade pip
      displayName: 'Upgrade pip'

    # Updating to latest Azure CLI version.
    - script: pip install --pre azure-cli --extra-index-url https://azurecliprod.blob.core.windows.net/edge
      displayName: 'Upgrade azure cli'

    - script: az --version
      displayName: 'Show Azure CLI version'

    - script: az extension add -n azure-devops
      displayName: 'Install Azure DevOps Extension'

    - script: echo ${AZURE_DEVOPS_CLI_PAT} | az devops login
      env:
        AZURE_DEVOPS_CLI_PAT: $(System.AccessToken)
      displayName: 'Login Azure DevOps Extension'

    - script: az devops configure --defaults organization=$(System.TeamFoundationCollectionUri) project="$(System.TeamProject)" --use-git-aliases true
      displayName: 'Set default Azure DevOps organization and project'

    - script: |
        set -euo pipefail
        if [[ "$(Build.SourceBranch)" == *"/release/"* ]]; then
          branchName="master"
        else
          branchName="develop"
        fi
        commandLine="--branch $branchName --name <YourPipelineName>"
        echo "Triggering release creation with: az pipelines run $commandLine"
        az pipelines run $commandLine
      displayName: Trigger release build for internal (develop) and external (release) builds
Run Code Online (Sandbox Code Playgroud)

注意事项

  • <YourPipelineName>适当更改,您的分支名称处理将与我的不同
  • Azure CLI 升级需要 1.5 分钟,所以如果你想显着加快它,只需删除前 3 个步骤
  • 我宁愿触发管道声明它自己的触发器,因为如果你能看到是什么导致它触发,它更容易维护,但是嘿嘿