Bitrise запускает рабочий процесс развертывания при отправке кода (когда этого не следует делать)

Я смущен, почему происходят следующие 2 вещи:

  1. Когда я отправляю некоторые коммиты в свою ветку feature_foo, запускаются 2 рабочих процесса (сборки): основной рабочий процесс для последней фиксации и рабочий процесс развертывания для моего последнего PR, оба на feature_foo. Я ожидал, что будет запущен только основной рабочий процесс, поскольку я еще не выдал PR.
  2. 2 одинаковых уведомления по электронной почте приходят мне от artifacts+\<my-bitrise-project-id\>@bitrise.io в течение одной минуты. Я понимаю, что 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. Run integration tests (primary workflow) on 2 occasions:
    1. Code push to * (any branch)
    2. Запросы на вытягивание в ветку feature (когда создается PR, т. е. предварительно объединенное состояние, чтобы участники могли предварительно просмотреть потенциальный эффект от предложенных ими изменений)
  2. Запустите развертывание (рабочий процесс развертывания) в staging, когда PR от * до feature ветки будут объединены
  3. Запуск развертывания (рабочий процесс развертывания) в рабочей среде при отправке тегов v*.*.*

Какова правильная конфигурация bitrise.yml для достижения этой цели? В документах не указано, как мы можем различать PR по состоянию ( выпущенные против объединенных). Я хочу развернуть только после проверки кода.

Спасибо


continuous-integration continuous-deployment bitrise
person kip2    schedule 24.10.2019    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если вы откроете PR, вызовет ли это новую сборку? Вы уверены, что PR еще не открыт?

Отвечать

Я хочу развернуть только после проверки кода.

Я предполагаю, что вы имеете в виду, когда PR просматривается и объединяется с целевой веткой, например. в master.

Для этого вы можете использовать такую ​​конфигурацию: https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-изтогожерепозитория

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

Это запустит сборку с использованием рабочего процесса под названием primary, когда вы открываете PR и каждый раз, когда вы обновляете PR. Обычно в этом случае вы хотите запустить некоторые автоматические тесты в рабочем процессе primary (модульные тесты/тесты пользовательского интерфейса, линтеры и/или, возможно, тестовая сборка).

Затем, когда вы объединяете PR (в данном случае с веткой master), он запускает сборку с использованием рабочего процесса deploy (поскольку технически слияние генерирует событие commit/push).

Я надеюсь, что это поможет, дайте мне знать, если у вас есть какие-либо вопросы!

person Viktor Benei    schedule 03.11.2019

arrow_upward
0
arrow_downward

Ответа Виктора достаточно, но я хотел бы добавить еще несколько выводов, которые могут иметь отношение к кому-то еще:

Когда я отправляю некоторые коммиты в свою ветку feature_foo, запускаются 2 рабочих процесса (сборки): основной рабочий процесс для последнего коммита и развертывание рабочего процесса для моего последнего PR, оба на feature_foo

Я считаю, что это произошло потому, что у меня был открытый PR, и я добавил дополнительные коммиты в исходную ветку этого PR. Основываясь на моей карте триггеров (поделенной выше в OP), в то время он запускал рабочий процесс deploy-staging. Карта триггеров, которой поделился Виктор, больше подходит для моего варианта использования.

Мне приходят 2 одинаковых уведомления по электронной почте от артефактов+\@bitrise.io в течение одной минуты

Оказывается, Bitrise отправляет как подписанный, так и неподписанный APK (для чего угодно) в двух отдельных электронных письмах.

person kip2    schedule 23.11.2019