在Azure Devop中触发YAML管道

Question

我是Azure Devops中的YAML构建管道的新手，并且我试图将自己的头放在触发功能上。令我困扰的是，我希望在不同的分支上使用不同的触发器，但我想使用相同的管道。

让我说要

1. 在master分支的所有签入基础上构建，并且应将其部署到服务器上
2. 每天晚上我都想构建并将development分支部署到另一台服务器

我很困惑，因为yaml文件也被检入到Git中。我读到，如果您已安排了触发器，那么您也无法拥有CI触发器。

我需要两个.yml文件吗？每个定义一个？重复所有步骤似乎不太酷

还是在每个分支中都应具有相同文件的不同版本？会不会在某个时候合并？

奖金问题：如果您在Developemt分支上将构建管道推送到master上触发，该怎么办？ （我会头晕）

Answer 1

我需要两个.yml文件吗？每个定义一个？重复所有步骤似乎不太酷

经过一段时间的研究，我个人建议您最好使用两个具有不同构建管道的.yml文件。

最直接的问题是master分支和development分支上的代码不是实时同步的。当两个分支上的代码不同时，生成结果也将不同。如果它们在同一个管道中，我们需要手动检查构建失败时错误来自哪个分支。这是一件痛苦的事情。

另一个深问题是我们可以在一个yaml文件中定义CI trigger和Scheduled trigger，例如：

trigger: 
 branches:
    include:
      - master


schedules:
- cron: "* 10 * * *"
  always: true
  displayName: Daily midnight build (UTC 22:00)
  branches:
    include:
     - Development

要实现此目的，我们需要在Development分支上设置此Yaml。如果我们更改master分支中的任何代码，它将触发该管道。 但是，它仅在Development分支上构建代码，在主服务器中不包含更改的代码。因此，此CI触发器将毫无意义。

在每个分支中，我应该使用同一个文件的不同版本吗？惯于 在某个时候合并？

个人建议您最好使用其他具有不同名称的Yaml文件。就像您说的一样，相同的文件在以后的分支合并中容易产生不必要的风险。

我的奖金问题更像是：您是否想保持与众不同 您在不同分支中的构建管道的版本？我的意思是如果我想要 每当我推动开发时建立开发分支都会触发 在yaml文件的master分支版本中定义？

答案是肯定的。您可以在yaml文件的 master 分支版本中使用简单的语法设置CI触发器：

trigger: 
 branches:
    include:
      - master
      - Development

使用此设置，每次您按下“开发”分支时，都会触发yaml文件的主分支版本中定义的构建。

注意：关于您的奖金问题，如果我们在CI触发器之上进行设置，则由于dev分支上的连续提交，管道将触发构建。有时我们只是修改自述文件，而不希望这样的修改触发不必要的构建，解决此类问题的最佳方法是使用 PR trigger 。

希望这会有所帮助。

Answer 2

您正在告诉您无法安排计划的触发器和CI触发器，但是事实并非如此。请检查文档here。

如果只想使用计划的触发器来运行管道，则可以 必须通过指定pr禁用PR和持续集成触发器： 无并触发：YAML文件中无。如果您使用的是Azure Repos 使用分支策略配置Git，PR构建，并且必须将其禁用 在那里。

所以您在这里有两个选择：

1. 将所有内容保存在一个YAML文件中，并检查触发了哪个分支或如何触发构建，以便将其部署到适当的服务器上
2. 您可以有两个构建，但是为了避免重复自己，请提取常见内容到模板并在构建定义中重复使用它们（因此，在这种情况下，您将拥有3个yaml文件）。

几个例子：

• 您只想为master分支机构工作：

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
  steps:
  - script: echo this only runs for master

• 您要提取常用步骤并在构建定义中重复使用它们

常用步骤：

# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
  type: boolean # data type of the parameter; required
  default: false

steps:
- script: echo ${{ parameters.yesNo }}

内部定义：

# File: azure-pipelines.yml
trigger:
- master

extends:
  template: simple-param.yml
  parameters:
      yesNo: false # set to a non-boolean value to have the build fail

您可以在the documentation中阅读有关模板的信息，或在我的blog post上查看示例。

如果要使用经典的发布管道，则需要定义两个发布管道，并触发特定分支。

总结：您可以做自己想做的事情，并且有多种方法可以实现这一目标。我个人的建议是使用带有模板的单独管道，因为它使构建定义比检查条件的条件更干净，以检查哪个分支或如何触发构建。

在此变量Build.Reason中，您可以检查分支的触发方式：

• 手动：用户手动将构建排队。
• IndividualCI：由Git推送或TFVC签入触发的持续集成（CI）。
• BatchedCI：通过Git推送或TFVC签入触发的持续集成（CI），并且已选择“批次”更改。
• 计划：计划的触发器。 ValidateShelveset：用户手动将 构建特定的TFVC货架集。
• CheckInShelveset：门控签到触发器。
• PullRequest：构建是由需要构建的Git分支策略触发的。
• BuildCompletion：该构建由另一个构建触发。
• ResourceTrigger：构建是由资源触发器触发的。

然后可以在条件中使用此变量。有关更多信息，请转到here。

结束语，请注意，有一种特殊的job称为deployment用于部署。如果要使用yaml管道部署应用程序，请考虑使用此功能。

关于奖金问题：您可以覆盖构建设置。我的意思是您可以为master和master分支触发。但是您仍然可以为其他分支（例如开发分支）运行构建（例如，通过手动运行）。那会发生什么呢？构建将针对新定义的分支运行。最后是构建定义，并仅触发控制自动构建执行。