1つまたは2つ以上のイベントにwebhookの登録をする際(例:Code Push
や Pull Request
イベント)、あなたのソースコードホスティングサービスはwebhookを関連したイベントが発生する度に呼び出します。
bitrise.ioではwebhookを呼び出すことをtriggers(トリガー)と呼んでおり、異なるWorkflows
へマップされたりされなかったりします。いかなるワークフローへのマップを望まない場合、bitrise.ioはビルドを開始しません。ワークフローへトリガーをマップすれば、ビルドは選択されたワークフロー上で開始されます。
以下の例では、選択されたワークフローIDだけが表示された非常にシンプルなBitriseの構成(bitrise.yml
)を使用します:
---
format_version: 1.3.0
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
trigger_map:
- push_branch: "*"
workflow: primary
- pull_request_target_branch: "*"
pull_request_source_branch: "*"
workflow: primary
- tag: "*"
workflow: primary
workflows:
primary:
steps:
- script:
inputs:
- content: |-
#!/bin/bash
echo "$BITRISE_TRIGGERED_WORKFLOW_ID"
上記の例では、bitrise.yml
はコードプッシュ毎(push_branch: "*"
)、タグプッシュ(tag: "*"
)、プルリクエスト毎(pull_request_target_branch: "*"
& pull_request_source_branch: "*"
)にprimary
ブランチを選択します。
trigger_map
リストから_プルリクエスト項目を削除する場合_、プルリクエストがビルドをトリガーする事はなくなります。例:
trigger_map:
- push_branch: "*"
workflow: primary
この構成はprimary
ワークフローを使ってコードプッシュ毎にビルドが開始されますが、それ以外(プルリクエストなど)では何も起こりません。
trigger_map
の構成要素 ⚓
trigger_map
というのは、_フィルターのリスト_を表しており、一定のフィルターのworkflow
がマッチするトリガーである場合選択されます。
少なくとも1つ以上のコンディションが全てのフィルター項目の中に含まれていなければなりません!
これはworkflow
と明記されただけの項目を持つことができないということであり、少なくとも1つのフィルター(push_branch
/ pull_request_source_branch
/ pull_request_target_branch
/ tag
)が明記されていなければなりません!
利用可能なフィルター: ⚓
push_branch
: コードプッシュイベントの”branch”パラメータの組み合わせpull_request_source_branch
: プルリクエストイベントの”source branch”パラメータ(プルリクエストが開始されたブランチ)の組み合わせpull_request_target_branch
: プルリクエストイベントの”target branch” パラメータ(プルリクエストがマージされるブランチ)の組み合わせtag
: タグプッシュイベントの”tag” (名前)パラメータの組み合わせpattern
: 非推奨 ー このフィルタはis_pull_request_allowed
との併用で、コードプッシュとプルリクエストイベントの両方で使われていました。現在このフィルタは、新しいフィルタがイベントマッピングにおいてより制御されてるので今は非推奨となっております。
単一項目内で複数のフィルタを定義する場合、その項目のワークフローを選択するために全てのフィルタがマッチされていないといけません。例:
trigger_map:
- pull_request_target_branch: "master"
pull_request_source_branch: "develop"
workflow: primary
これはプルリクエストのソースブランチがdevelop
で且つターゲットブランチがmaster
である場合、primary
ワークフローのみを選択します。
別々に処理されなければならないフィルターを明記したい場合、(例)ソースがdevelop
であるプルリクエストではprimary
を選ぶか、同時にmaster
をターゲットするプルリクエストを選びます:
trigger_map:
- pull_request_target_branch: "master"
workflow: primary
- pull_request_source_branch: "develop"
workflow: primary
最後に、同一項目内においてpush_branch
、tag
、pull_request_..
フィルタを混合させたり、マッチしたりすることはできません。これは事実上、イベントが同時のコードプッシュとプルリクエスト(もしくはタグプッシュ)イベントである場合、そのワークフローが選択する必要があることを表します。ソースコードホスティングサービスがプルリクエスト(プリマージ状態)、タグ、そしてコードプッシュイベントで別々のwebhookに送信することはできません。単一のwebhookイベントではコードプッシュ、タグプッシュ、プルリクエストを同時に行うことはできません。一つのwebhookでは常に一種類のみ(コードプッシュ、タグプッシュ、もしくはプルリクエスト)が関連付けられます。
単一トリガー = 単一ビルド ⚓
トリガー一つにつき、単一のワークフローのみを選ぶことができ、一つのビルドのみを開始することができます。トリガーにマッチする最初の項目がビルドのワークフローを選択します!
2つ以上のワークフローを走らせたい場合、互いにワークフローのチェーニングを行うことができます。チェーンされたワークフローは並行して走ることはありませんが、ワークフローをチェーンすれば全てのワークフローが実行されます。
項目の順番にもお気をつけください: _push_branch: "*"_
項目の後にpush_branch: mast
を明記した場合、push_branch: master
は選択されることはありません。コードプッシュイベント毎に push_branch: "*"
が始めにマッチし、トリガーにマッチする最初の項目はビルドのワークフローを選択します!
単一ブランチのみのビルド方法 ⚓
単一ブランチのみのビルドをコードプッシュ毎に行いたい(それ以外に何も行わない)場合、ほかのどのワークフローへのマッピングを行わないtrigger_map
(ビルドを行いたいブランチだけ)を明記してください。
例えば、コードプッシュでmaster
ブランチのみをビルドしたい場合:
trigger_map:
- push_branch: master
workflow: primary
feature/
ブランチのみのビルドを行いたい場合:
trigger_map:
- push_branch: feature/*
workflow: primary
2つ同時にする場合:
trigger_map:
- push_branch: master
workflow: primary
- push_branch: feature/*
workflow: primary
この構成はmaster
かfeature/
ブランチのどちらかで発生するコードプッシュ毎にビルドが開始され、両方で同じワークフロー(primary
)を使用します。
ご自身のmaster
ブランチにおいて異なるワークフローを使用したい場合、トリガーマップ項目のworkflow:
を変更してください。
trigger_map:
- push_branch: master
workflow: deploy
- push_branch: feature/*
workflow: primary
この構成では、master
上においてコードプッシュ毎にワークフローdeploy
を使用し、feature/
ブランチ上のコードプッシュ毎にワークフローprimary
を使用します。他のビルドは開始されません。
簡単で2つのワークフローのCI/CDセットアップ ⚓
ベースとなるCI/CDセットアップは2つのワークフローを伴います。一つがintegration tests(インテグレーションテスト)で、もう一方はdistribution(配布)になります。
インテグレーションテストを行うワークフローprimary
、デプロイ/配布を行うワークフローdeploy
をお持ちで(deploy
ワークフローを使用せずに)、master
ブランチ以外でのでコードプッシュやプルリクエストのインテグレーションテストをブランチ毎で行いたい場合:
trigger_map:
- push_branch: master
workflow: deploy
- push_branch: "*"
workflow: primary
- pull_request_target_branch: "*"
workflow: primary
同一レポジトリからプルリクエストによる2つのビルドを開始しないでください ⚓
同じレポジトリ(forkからではなく、レポジトリのブランチから)からプルリクエストを開始するとき、ソースコードホスティングサービスは2つのwebhook(コードプッシュとプルリクエスト)を送信します。
プルリクエストにおいて、両方もしくは一つだけのビルドを行う場合はプロジェクトの必要条件次第となりますが、bitrise
を使用すると、それを行うかどうかを決めることができます。
master
をデプロイすることに加えて、プルリクエスト(”プリマージされた”)イベント/状態のみのビルドを行う一例:
trigger_map:
- push_branch: master
workflow: deploy
- pull_request_target_branch: "*"
workflow: primary
プルリクエストのビルドを開始せずにコードプッシュイベントのみを開始する際の一例:
trigger_map:
- push_branch: master
workflow: deploy
- push_branch: "*"
workflow: primary
3つのワークフロー:テスト、stagingのデプロイ、productionのデプロイ ⚓
他の共通のCI/CDパターンには3つのワークフローが存在します:
- プルリクエスト毎に走るTest workflow(テストワークフロー)は
feature/
ブランチ上などでのコードプッシュ毎にそのテストがリリース(ブランチ)へ統合されるかどうかをテストします。 - Staging Deployment Workflowは内部/テストシステムへアプリ/コードのデプロイを行います。例:
- iOSアプリの場合の例としては、IPAへ署名したAd Hocが、テスターチームがダウンロードしたりテストを行うHockeyAppへデプロイされる、もしくは、内部テスト用のiTunes Connect/Testflightへのデプロイとなります。
- Androidアプリの場合、Google Playから”beta”トラックへのデプロイとなります。
- サーバーコードの場合の例としては、Staging Herokuサーバーへのデプロイとなります。
- Production deployment workflowはアプリ/コードをProductionへデプロイします。
- iOSアプリの場合、IPAへ署名したApp StoreがiTunes Connect/TestFlightへデプロイされ、”外部テスト”で有効化されます。
- Androidアプリの場合、Google Playへのアプリの公式アップデートとしてのデプロイとなります。
- サーバーコードの場合の例としては、production Heroku サーバーへのデプロイとなります。
primary
(テスト)、deploy-to-staging
、deploy-to-production
の3つのワークフローがあることがわかりました。3つのトリガーを明記することで正しいトリガーに正しいワークフローを選択することができます。
2つの類似したアプローチもありますが、これはご自身が選ぶproduction デプロイのブランチのタグ次第となります。
productionデプロイをトリガーするタグの使用 ⚓
trigger_map:
- tag: v*.*.*
workflow: deploy-to-production
- push_branch: master
workflow: deploy-to-staging
- push_branch: "*"
workflow: primary
- pull_request_target_branch: "*"
workflow: primary
このトリガーマップ構成はビルドをトリガーします。
- 新しいタグ(フォーマット
v*.*.*
,v1.0.0
を使用)がプッシュされた場合のdeploy-to-production
ワークフローを使用するとき - コードプッシュが
master
ブランチ上で発生する場合のdeploy-to-staging
ワークフローを使用するとき - 他のブランチ全般・プルリクエストの
primary
ワークフローを使用するとき
productionデプロイをトリガーするブランチの使用 ⚓
trigger_map:
- push_branch: master
workflow: deploy-to-production
- push_branch: develop
workflow: deploy-to-staging
- push_branch: "*"
workflow: primary
- pull_request_target_branch: "*"
workflow: primary
このトリガーマップ構成はビルドをトリガーします:
master
ブランチ上でコードプッシュが発生する場合のdeploy-to-production
を使用するとき(例:master
へgit flow リリースブランチをマージしたとき)- コードプッシュが
develop
ブランチ上で発生する場合のdeploy-to-staging
を使用するとき(例:プルリクエストがdevelop
ブランチへマージされる時) - 他のブランチ全般・プルリクエストの
primary
ワークフローを使用するとき
プルリクエストのみでビルドを行う方法 ⚓
プルリクエストのインテグレーションテストだけを走らせたい場合、以下のようなトリガーマップ構成を使用できます:
trigger_map:
- pull_request_target_branch: "*"
workflow: primary
これによりプルリクエスト毎にprimary
ワークフローが選択され、それ以外のビルドは開始されません。
master
へマージされるようにターゲットされたプルリクエストのビルドのみを行いたい場合、構成は以下のようになります。
trigger_map:
- pull_request_target_branch: master
workflow: primary