1

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

  1. 当我将一些提交推送到我的feature_foo分支时，会运行 2 个工作流程（构建）：针对最新提交的主要工作流程，以及针对我上次 PR的部署工作流程，两者都在feature_foo. 我希望只运行主要工作流程，因为我还没有发布 PR
  2. artifacts+\<my-bitrise-project-id\>@bitrise.io在同一分钟内向我发送了 2 封相同的电子邮件通知。我知道 PR可以导致两次构建（因为 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 工作流设置：

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

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

谢谢

4

2 回答 2

2

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

回答

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

我猜你的意思是当 PR 被审查并合并到目标分支时，例如合并到master.

为此，您可以使用这样的配置：https ://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-from-the-same -存储库

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

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

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

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

于 2019-11-03T15:56:13.983 回答
0

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

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

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

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

事实证明，Bitrise 在两封单独的电子邮件中同时发送了签名和未签名的 APK（无论如何）

于 2019-11-23T20:11:13.250 回答