问题标签 [build-triggers]

我正在尝试通过 PowerShell 脚本使用 REST API 更新 Azure DevOps 中的构建定义...

Azure DevOps 文档中并没有特别清楚我应该如何使用这种方法更新构建定义，但是上面会导致以下错误：

Invoke-RestMethod : {"$id":"1","innerException":null,"message":"值不能为空。\r\n参数名称：define.Repository " ,"typeName":"System.ArgumentNullException, mscorlib","typeKey":"ArgumentNullException","errorCode":0,"eventId":0}

这就是我想知道我是否在吠叫错误的树的地方，因为这肯定会更简单（我在 SO 上找到了一个简单的解决方案，用于创建新的构建定义）。事实上，我想做的只是更新触发器分支过滤器。

如何使用 PowerShell 和 REST API 实现此目的？

需要在 PR 合并到 master 时触发 CI 构建作业（仅当更改在 ./rel/* 路径内时）但在创建 Pull Request (PR) 时不触发 CI 构建。所以我有如下的触发器配置。

但添加时无法触发 CI 构建pr: none。如果pr: none被删除，则 PR 和合并到 master 都会触发 Job。我只需要在合并到 master 的情况下运行作业/CI 构建。

我有一个用于 repo 的 CI 构建触发器设置，如下所示：

我有同一个 repo 的一个分支，我想拥有它自己的管道。

在我拥有的分支的 pipeline.yml 中：

但是，如果我将更改提交到我的分支，主管道和分支管道都会触发构建。

提交到 master 也会触发分支的管道（它不应该）。

我曾尝试使用branches节点排除主节点，但似乎没有任何效果。看：

唯一似乎阻止针对主管道触发构建的是，如果我使用通配符运算符排除所有内容 - 然后不会触发构建。

如果有影响，我将在 Azure DevOps 门户中进行这些更改。

这似乎是一件非常微不足道的事情，但我不明白为什么我会为同一个提交触发两个管道，即使设置了排除项。

我的完整 YAML 文件如下所示：

任何建议，将不胜感激。

要求

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

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

管道 A 语法

当前行为

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

问题/评论

• Pipeline 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（我的原始场景）
• 哦，太高兴了 :-) 有一个 az azure devops 命令行扩展，它获得了管道支持并允许您触发管道：
  • 要安装：https ://docs.microsoft.com/en-us/azure/devops/cli/?view=azure-devops
  • 管道运行文档：https ://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines?view=azure-cli-latest#ext-azure-devops-az-pipelines-run
  • 管道触发命令示例：az pipelines run --branch master --name "<PipelineName>" --org "https://dev.azure.com/<OrganisationName>" -p "<ProjectName>"
  • Azure DevOps 集成示例：https ://docs.microsoft.com/en-us/azure/devops/cli/azure-devops-cli-in-yaml?view=azure-devops

我有一大组 GCP Cloud Build 触发器，我通过云调度程序调用它们，它们都运行良好。现在，我想通过外部 API 调用来调用这些触发器，并向它们传递值和参数数量不同的动态参数。

我能够通过运行 API 请求来启动触发器，但我发送的 API 请求中的任何 JSON 参数都被忽略了。Google 在https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values讨论替换参数。我在 cloudbuild.yaml 文件中定义了这些变量，但是它们没有从 API 请求传播到我的 shell 脚本中。我在身份验证或授权方面没有任何错误，因此安全性可能不是问题。

我的想法是否完全受支持，或者我是否需要求助于其他解决方案，例如运行带有容器的 GKE 集群，这些容器会暴露其 API（一个非常繁重的解决方案）。

我有两个工作，p1 和 p2。

触发 p2 的条件：

1. p1构建完成

2. 每逢星期一

但我知道“构建其他项目后构建”和“定期构建”不会同时触发。有没有办法解决这个问题？

我有一个包含不同云功能文件夹的项目文件夹，例如

现在我现在拥有的是。我将代码从 Cloud Fucntions 文件夹一一推送到 Source Repository 到 Source Repository（每个函数文件夹单独的 Repos）。然后它启用了触发云构建然后部署功能的触发器。我拥有的 cloudbuild.yaml 文件如下所示。

现在，我想做的是我想做一个单一的源代码库，每当我更改一个云函数中的代码并推送它时，只有它得到部署，其余的仍然像以前一样。

更新

现在我也在下面尝试了类似的方法，但它也同时部署了所有功能，即使我正在处理一个功能。

cloudbuild.yaml 文件如下所示

我有两个构建我的客户端和 API 的构建管道，但是当我创建一个新的 git 标签时，两个构建都会被触发，即使标签可能只与基于我的客户端代码的更改有关。

前端构建-ci.yml

api-build-ci-yml

定期提交按预期工作（即客户端代码触发客户端构建），我尝试了多种排除路径的变体无济于事。

标签过滤应该忽略路径，还是应该以与分支相同的方式工作？

一种解决方法是使用更多描述性标签（即20200326_prodrelease_api），但如果 api 和客户端都准备好进行生产，我会尽量避免需要两个标签。

我对触发器部分下的 TFS 2017 Build 中提供的选项有点困惑。我有两个单独的构建定义，一个用于代码签入，即称为门控构建，另一个是手动构建，我们用于在门控构建完成后在我们的 CI 服务器上进行代码删除\部署。

最近，我们考虑直接使用 Gated 构建定义进行代码删除，这样可以节省单独触发手动构建的时间。但是，在执行此 POC 时，我对使用“触发器”部分中可用的不同功能感到困惑，尤其是“为提交的更改运行持续集成触发器”

我已经将 Gated Build 与 Release Definition 直接关联起来，一旦 Gated Build 完成，它就会部署代码。我在构建中选择了两个选项，即为 过滤器使用工作区映射和为提交的更改运行持续集成触发器。每当我签入代码时，构建完成后都会触发发布定义并将代码部署在服务器上，但是当我取消选择运行持续集成触发器以进行提交的更改并签入代码时，它仍然会部署代码，因为它与发布定义相关联。

我在谷歌上搜索并试图了解它的使用和其他功能，但不太了解，我通过链接也知道它不会在变更集中显示 NO CI。

任何人都可以解释触发器下存在的每个功能\选项的确切用途，除了计划的一个，或者如果有任何其他链接、博客、视频教程，请告诉我任何知道触发器选项下所有功能的解释的人深入举例？

在 CI 构建中启用了持续集成选项，因为它会在门控构建完成后自动触发。

每次推送到 Github 存储库时，我一直在使用 GCP 触发器来部署一个新的 pod。我已经完成所有设置，docker 镜像被推送到 GCP 容器注册表，触发器成功完成，没有任何错误。我使用构建管道生成的$SHORT_SHA标签作为我的标签。但是，新的 pod 部署不起作用。我不确定问题是什么，因为我正在修改代码库以及每次新推送只是为了测试部署。我已经按照 Google 关于触发器的几个教程进行操作，但我无法理解究竟是什么问题以及为什么新推送的图像没有被部署。

cloudbuild.yaml

Kubernetes.yaml