GitHub

トリガーマップを使ったビルドのトリガー

1つまたは2つ以上のイベントにwebhookの登録をする際(例:Code PushPull 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とは何ですか。

bitrise.ymlはあなたのアプリの構成を表します。workflow editorでは、ウェブUI経由のビジュアル的方法を使った編集も可能ですが、いつでもbitrise.ymlモード(workflow editorの左側)に切り替えてYAMLフォーマットの構成を確認することができます。同様にYAMLフォーマットでの編集も可能です。ビジュアルウェブUIかYAML(bitrise.yml)のどちらかを選んでください。いつでも変更が可能です。(ウェブUIからYAMLに切り替える場合、すぐにbitrise.ymlに反映されます。逆も同じです。)

上記の例では、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)が明記されていなければなりません!

利用可能なフィルター:

単一項目内で複数のフィルタを定義する場合、その項目のワークフローを選択するために全てのフィルタがマッチされていないといけません。例:

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_branchtagpull_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

この構成はmasterfeature/ブランチのどちらかで発生するコードプッシュ毎にビルドが開始され、両方で同じワークフロー(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

項目の順番にご注意ください!

bitriseがwebhookイベント(どんな種類でも)を受理する時、アプリのtrigger_mapに対してマッチします。マッチする最初の項目がビルドのワークフローを選択します!

これはpush_branch: "*" 項目のpush_branch: masterを明記することで、コードプッシュイベント毎に始めに push_branch: "*" がマッチするので、masterが選択されることはありません。

同一レポジトリからプルリクエストによる2つのビルドを開始しないでください

同じレポジトリ(forkからではなく、レポジトリのブランチから)からプルリクエストを開始するとき、ソースコードホスティングサービスは2つのwebhook(コードプッシュとプルリクエスト)を送信します

Pull Request buildプルリクエストのビルド

両方のビルドが同じように思えますが、本当はそうではありません。ビルド毎のコードプッシュイベントでは、マージなどすることはなく、ブランチのコードをビルドします。ブランチからチェックアウトするときに、アナラがお持ちの全く同じ状態のコードをビルドします。一方で、プルリクエストのビルドは\”プリマージ\”状態のコードのビルドも行います。この\”プリマージ\”状態とは、コードの最終的なマージされたバージョンではなく、プルリクエストをマージしたに表示されるであろうコードのクローンのようなものを表します。

プルリクエストにおいて、両方もしくは一つだけのビルドを行う場合はプロジェクトの必要条件次第となりますが、bitriseを使用すると、それを行うかどうかを決めることができます。

プルリクエストのマージはコードプッシュのことです。

ソースコードホスティングサービスはコードプッシュイベントとしてイベント\”マージ\”を処理します。例えば、feature/aからmasterへプルリクエストをマージする場合、PRをマージするとmasterへのコードプッシュが生成されます。

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つのワークフローが存在します:

primary(テスト)、deploy-to-stagingdeploy-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

このトリガーマップ構成はビルドをトリガーします。

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

このトリガーマップ構成はビルドをトリガーします:

プルリクエストのみでビルドを行う方法

プルリクエストのインテグレーションテストだけを走らせたい場合、以下のようなトリガーマップ構成を使用できます:

trigger_map:
- pull_request_target_branch: "*"
  workflow: primary

これによりプルリクエスト毎にprimaryワークフローが選択され、それ以外のビルドは開始されません。

masterへマージされるようにターゲットされたプルリクエストのビルドのみを行いたい場合、構成は以下のようになります。

trigger_map:
- pull_request_target_branch: master
  workflow: primary