我如何在 azure 管道中通过分支 AND 标签触发?

CDN*_*CDN 3 azure-devops azure-pipelines

我想创建一个 azure 管道,这样当我推送到分支(开发)标记(测试*)时,管道将被触发。但是,当我推送到没有标签的分支(开发)时,管道会被触发,这表明在推送到(开发)分支(测试*)标签时触发器正在执行。

例子:

trigger:
  branches:
    include:
      - develop
      - refs/tags/{test*}
Run Code Online (Sandbox Code Playgroud)

仅当推送到(开发)分支有对(测试*)标签的引用时,如何才能触发触发器?

Jos*_*ust 6

根据触发器的文档

当您指定触发器时,它会替换默认的隐式触发器,并且只有推送到明确配置为包含的分支才会触发管道。首先处理包含,然后从该列表中删除排除。

我认为文档中缺少(或只是令人困惑)的是,满足给定部分(分支、路径、标签)中包含的任何 1 项的项目为该部分列出,如果它们满足该部分的任何 1 个排除子句,则将其删除。除非使用了所有三个部分。那么以下注意事项适用:

如果指定与分支的过滤器组合而成的代码,其中包括文件路径,如果分支滤波器满足触发条件会,要么标签路径滤波器满足。

概括

include:集合首先创建并excludes从该列表中删除。

部分是OR ed在一起(branches OR tags)(branches OR paths)除非使用所有部分,否则它们是(branches AND (tags OR paths))

考虑到这一点:

如果您只想继续使用分支部分,则需要使用从列表中删除所有不需要的分支并仅显式包含标记 ref(视为分支)的选项。

包含标签并排除不需要的分支模式

trigger:
  branches:
    include:
    - refs/tags/test*
    exclude:
    # a list of the branches for which you don't want to trigger
    - master
    - features/*
    - bugs/*
    - hotfix/*
Run Code Online (Sandbox Code Playgroud)

如果您不受限于仅使用分支部分,那么使用所有 3 个部分将通过包含develop分支和test*标签但排除所有路径来实现。

包括标签和所需的分支,但排除该分支上的所有路径

trigger:
  branches:
    include:
      - develop
  tags:
    include:
      - test*
  paths:
    exclude:
      - /*
Run Code Online (Sandbox Code Playgroud)

这第二个选项基本上shouldFire = (branch == develop && (tag == test* || false))相当于shouldFire = (branch == develop && tag == test*)

  • 我可以确认上面带有路径排除的第二个示例不再按所述工作。当标签应用于功能分支时,会触发在功能分支上使用该语法的测试作业。 (2认同)

mko*_*oro 6

上面 Josh Gust 的答案在当时可能是正确的,但不幸的是现在似乎不再是这样了。

Azure 文档的最新更新完全改变了包含/排除逻辑的工作方式。

考虑到这一点,在我看来,除了特定的分支加标签组合之外,没有办法完全阻止管道的触发。这是非常不幸的。

下一个最好的事情似乎是尽早中止管道。您可以执行以下操作:

  • 确保管道设置为仅在所需标签存在时触发。使用标准tags include设置来实现这一点。
  • 替代方案 1:作为第一步,如果分支名称不是您期望的名称,则有条件地以“已取消”形式中止构建。这似乎非常复杂,您可能会想要使用这样的库。
  • 替代方案 2:eq(variables['Build.SourceBranchName'], 'master')为管道中的每个步骤添加类似的条件。这很乏味,但很简单。

当确定在 YAML 脚本中使用哪个分支名称时,记住文档中的这一警告很有用前提是您使用的是 Git):

Build.SourceBranchName:参考中的最后一个路径段。例如,refs/heads/master该值为master. 在refs/heads/feature/tools这个值是tools.

从您 2 月 12 日的评论来看,我认为 Josh 的建议当时对您有效。如果您能确认它是否仍按预期工作,我们将不胜感激。如果它仍然有效,那么 Azure 文档更新一定是错误的,我想就此向他们提出问题。