2

I am confused why the following 2 things happen:

  1. When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo. I expected only the primary workflow to be run as I haven't issued a PR yet
  2. 2 identical email notifications are sent to me from artifacts+\<my-bitrise-project-id\>@bitrise.io within the same minute. I understand that a PR can lead to two builds (as a PR is technically a push), but doubt that is the issue here as I've not created a PR yet.

Here is my current bitrise.yml trigger map:

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

By the way, this is my desired 3-workflow setup:

  1. Run integration tests (primary workflow) on 2 occasions:
    1. Code push to * (any branch)
    2. Pull requests to feature branch (when the PR is created i.e. pre-merged state so contributors can preview the potential effect of their proposed changes)
  2. Run deployment (deploy workflow) to staging when PRs from * to feature branch are merged
  3. Run deployment (deploy workflow) to production when tags v*.*.* are pushed

What is the correct bitrise.yml config to achieve this? The docs do not indicate how we can differentiate PRs by state (issued vs merged). I want to deploy only after the code has been reviewed.

Thanks

kip2
  • 6,473
  • 4
  • 55
  • 72

2 Answers2

3

If you open the PR will that trigger another build? Are you sure the PR isn't opened yet?

To answer

I want to deploy only after the code has been reviewed.

I guess you mean when the PR is reviewed and merged into the target branch e.g. into master.

For that you can use a config like this: 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

This will run a build using the workflow called primary when you open the PR and every time you update the PR. Typically you want to run some automated tests in this case, in the primary workflow (unit/ui tests, linters and/or doing maybe a test build).

Then when you merge the PR (in this case into the master branch) it'll trigger a build using the deploy workflow (as technically a merge generates a commit/push event).

I hope this helps, let me know if you have any questions!

Viktor Benei
  • 3,447
  • 2
  • 28
  • 37
1

Viktor's answer is sufficient, but I wanted to add some more findings that might be relevant to someone else:

When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo

I believe this happened because I had an open PR and pushed additional commits to the source branch of that PR. Based on my trigger map (shared above on the OP) at that time, it would run a deploy-staging workflow. The trigger map shared by Viktor makes more sense for my use case

2 identical email notifications are sent to me from artifacts+\@bitrise.io within the same minute

Turns out Bitrise sends both a signed and an unsigned APK (for whatever) in two separate emails

kip2
  • 6,473
  • 4
  • 55
  • 72