Bitrise 在代码推送上运行部署工作流（当它不应该时）答案

【问题标题】：Bitrise Runs Deployment Workflow on Code Push (when it shouldn't)Bitrise 在代码推送上运行部署工作流（当它不应该时）
【发布时间】：2019-10-24 20:12:08
【问题描述】：

我很困惑为什么会发生以下两件事：

当我将一些提交推送到我的 feature_foo 分支时，会运行 2 个工作流程（构建）：针对最新提交的主要工作流程，以及针对 我的上一个 PR 的部署工作流程，两者都在 @987654324 @。由于我还没有发布 PR，我希望只运行主要工作流
在同一分钟内，artifacts+\<my-bitrise-project-id\>@bitrise.io 向我发送了 2 封相同的电子邮件通知。我知道 PR can lead to two builds（因为 PR 在技术上是一种推动），但我怀疑这是这里的问题，因为我还没有创建 PR。

这是我当前的 bitrise.yml 触发图：

trigger_map:
- push_branch: "*"
  workflow: primary
- pull_request_source_branch: "*"
  pull_request_target_branch: feature
  workflow: deployment-staging
- tag: "v*.*.*"
  workflow: deployment-production

顺便说一下，这是我想要的 3 工作流设置：

在 2 次运行集成测试（主要工作流程）：
1. 代码推送到 *（任何分支）
2. 将请求拉到feature 分支（在创建 PR 时，即预合并状态，以便贡献者可以预览他们提议的更改的潜在影响）
当从 * 到 feature 分支的 PR 合并时，运行部署（部署工作流）到 staging
当标签v*.*.*被推送时，将部署（部署工作流）运行到生产

实现此目的的正确 bitrise.yml 配置是什么？ docs 没有说明我们如何按状态区分 PR（已发布与已合并）。我只想在审查代码后进行部署。

谢谢

【问题讨论】：

标签： continuous-integration continuous-deployment bitrise

【解决方案1】：

如果您打开 PR 会触发另一个构建吗？确定 PR 还没打开？

回答

我只想在代码审核后进行部署。

我猜你的意思是当 PR 被审查 并合并 到目标分支例如进入master。

为此，您可以使用如下配置：https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-from-the-same-repository

trigger_map:
- push_branch: master
  workflow: deploy
- pull_request_target_branch: "*"
  workflow: primary

这将在您打开 PR 和每次更新 PR 时使用名为 primary 的工作流运行构建。通常，在这种情况下，您希望在 primary 工作流中运行一些自动化测试（单元/ui 测试、linter 和/或进行测试构建）。

然后，当您合并 PR（在本例中为 master 分支）时，它将使用 deploy 工作流触发构建（因为从技术上讲，合并会生成提交/推送事件）。

希望对您有所帮助，如果您有任何问题，请告诉我！

【讨论】：

【解决方案2】：

Viktor 的回答就足够了，但我想补充一些可能与其他人相关的发现：

当我将一些提交推送到我的 feature_foo 分支时，会运行 2 个工作流程（构建）：针对最新提交的主要工作流程，以及针对我上次 PR 的部署工作流程，都在 feature_foo 上

我相信这是因为我有一个开放的 PR 并将其他提交推送到该 PR 的源分支。根据我当时的触发图（上面在 OP 上共享），它将运行 deploy-staging 工作流。 Viktor 共享的触发器映射对我的用例更有意义

在同一分钟内从 artifacts+\@bitrise.io 向我发送了 2 个相同的电子邮件通知

原来 Bitrise 在两封单独的电子邮件中同时发送了一个签名和一个未签名的 APK（不管怎样）

【讨论】：