【问题标题】:How do you trigger a CD pipeline dependent on a CI pipeline succeeding?您如何触发依赖于 CI 管道成功的 CD 管道?
【发布时间】:2021-06-04 12:41:51
【问题描述】:

我想要:

  • PipelineA 在成功完成后构建并上传工件
  • PipelineB 运行并下载 PipelineA 的工件

PipelineA 的触发器:

trigger:   
    branches:
        include:
        - release/*
        - master  

这按预期工作,每当进行代码更改时,PipelineA 都会运行并构建一个工件。

PipelineB 的触发器(不起作用!)

trigger: none # important! we do not want to be deploying to environments without an artifact

resources: 
    pipelines:
    - pipeline: PipelineALocal # does not matter, only for pulling down local vars
      source: PipelineA # the exact name defined in ADO
      trigger: true # tried every variant under the sun to get this working but this pipeline will never run

我已经尝试了所有触发器组合,包括(显然应该始终有效trigger: true?)但没有任何效果。管道永远不会触发。

resources.pipelines.branches.include 下,我尝试过:refs/heads/mastermasterrefs/heads/release/*release/* 以及介于两者之间的所有内容。当然要使用正确的 YAML 格式。

The documentation 非常令人困惑,但我设法弄清楚如何从管道别名中获取 runID

--

我已经尝试通过触发器 UI 并根据 PipelineA 成功配置 PipelineB 构建完成触发器。

这仅适用于 master 分支,因此我无法使用 variables['Build.SourceBranch'] 来确定这是暂存版本还是发布版本。

如何根据 CI 管道成功触发 CD 管道?

【问题讨论】:

  • PipelineA 的构建是完全成功还是部分成功?
  • 您是否曾经在 UI 中为管道设置过触发器? (编辑 -> 省略号 -> 触发器)
  • 是 PipelineA 的构建成功。 -- 我确实使用了省略号 UI,它适用于 master。但我也需要能够控制release 管道。 variables['Build.SourceBranch'] 在 CD 管道中总是变成 master,这是不好的。当管道首先应该可以通过 Yaml 完全配置时,我为什么要这样做? ??????
  • 嗨@user5812916,进展如何?我注意到@BartoszPelikan 的回答中有一些很好的建议。请与他们核对一下。

标签: azure-devops continuous-integration yaml continuous-delivery


【解决方案1】:

这些管道有什么分离的情况吗?

我对 CI 和 CD 使用阶段仅使用一个 yml,并且依赖于 CI 阶段的成功:


stages:
- stage: CI
  jobs:
  - job:
    ...

- stage: CD
  dependsOn: CI
  jobs:
  - job:
    ...

编辑2:

我试过了

trigger: none

resources: 
    pipelines:
    - pipeline: cd-test
      source: ci-pipeline
      trigger: true

在我的项目中,这工作正常,但您必须记住,PipelineB(在我的情况下为 ci-pipeline)中的触发器必须在 master 分支上,当我从 master 删除它们时它停止工作。


编辑1:

要启用从另一个管道触发,您必须转到 Edit Pipeline definition -> Triggers

并设置触发器:

【讨论】:

  • 分离管道是最佳实践,因为构建可能用于 PR 验证,或者更重要的是,生成发布工件。发布管道是独立的,因此它可以搭载成功的构建(用于发布)。
  • 要实现您的目标,您可以使用 stage Conditions。我不确定 Azure DevOps 中是否可以将两个管道作为完全独立的文件运行。现在我真的很好奇这是否可能。在所有微软文档中,我只看到了StagesConditions 的相关信息,我从未听说过这样的案例。
  • 什么?当您创建新管道时,它实际上会提示为新管道创建一个新文件。
  • @denvercoder “分离管道是最佳实践”。根据谁?我很少建议这样做。您可以使用条件来指定仅应在 PR 期间运行或仅在从 PR 触发时运行的阶段或作业。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多