トリガーマップを使用してビルドをトリガーする
1つのイベントまたは複数のイベント(たとえば、 code push
とのために pull request
イベント)、関連するイベントが発生するたびに、ソースコードホスティングサービスがWebhookを呼び出します。
オン bitrise.io これらのWebhook呼び出しはトリガーと呼ばれ、さまざまなワークフローにマップすることも、まったくマップしないこともできます。トリガーをワークフローにマップしない場合は、 bitrise.io ビルドを開始しません。ワークフローにマップすると、選択したワークフローでビルドが開始されます。
次の例では、非常に単純なBitrise構成を使用します(bitrise.yml
)、これは選択したワークフローのIDを出力するだけです。
bitrise.ymlファイルとは何ですか
NS bitrise.yml
fileは、アプリの構成をYAML形式で表現したものです。あなたはできる:
-
ファイルをローカルで編集し、リポジトリに保存します。
-
上のファイルを編集します bitrise.yml 上のワークフローエディタのタブ bitrise.io。
-
ワークフローエディターのグラフィカルUIでステップとワークフローを更新します。すべての変更はに反映されます
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: "*"
)。
この構成により、ビルドが開始されます。 主要な すべてのコードプッシュのワークフロー。ただし、他には何もありません(たとえば、プルリクエストのワークフローではありません)。
トリガーマップのコンポーネント
NS trigger_map
フィルタのリストであり、 workflow
トリガーが一致する場合に選択する必要のある特定のフィルターです。すべてのフィルターアイテムには、少なくとも1つの条件が含まれている必要があります。
これは、を指定するだけのアイテムを持つことはできないことを意味します workflow
、少なくとも1つのフィルター(push_branch
/ pull_request_source_branch
/ pull_request_target_branch
/ tag
)を指定する必要があります!
利用可能なフィルター:
-
push_branch
:コードプッシュイベントのブランチパラメーターと照合されるフィルター。 -
pull_request_source_branch
:プルリクエストイベントのソースブランチパラメーター(プルリクエストが開始されたブランチ)と照合されるフィルター。 -
pull_request_target_branch
:プルリクエストイベントのターゲットブランチパラメータと照合されるフィルタ-プルリクエストがマージされるブランチ。 -
tag
:タグプッシュイベントのタグ(名前)パラメーターと照合されるフィルター。 -
pattern
:非推奨-このフィルターは、コードのプッシュイベントとプルリクエストイベントの両方に使用され、is_pull_request_allowed
。新しいフィルターを使用するとイベントマッピングをより適切に制御できるため、このフィルターは非推奨になりました。
1つのトリガー= 1つのビルド
1つのトリガーは単一のワークフローのみを選択できます/単一のビルドのみを開始できます。トリガーに一致する最初のアイテムは、ビルドのワークフローを選択します!
アイテムの順序も重要です。
trigger_map: - push_branch: "*" push_branch: "master*" workflow: primary
指定することにより push_branch: master
後のアイテム push_branch: "*"
アイテム、 push_branch: master
すべてのコードプッシュイベントが一致するため、選択されることはありません push_branch: "*"
最初に、トリガーに一致する最初のアイテムがビルドのワークフローを選択します!
1つのアイテムに複数のフィルターを定義する場合、そのアイテムのワークフローを選択するには、すべてのフィルターが一致する必要があります。例えば:
trigger_map: - pull_request_target_branch: "master" pull_request_source_branch: "develop" workflow: primary
これは、 primary
プルリクエストのソースブランチが develop
そして、ターゲットブランチは master
。
個別に処理する必要があるフィルターを指定する場合、たとえば、 primary
ソースが develop
、および対象となるものを選択します master
:
trigger_map: - pull_request_target_branch: "master" workflow: primary - pull_request_source_branch: "develop" workflow: primary
同じアイテムにフィルターを混在させることはできません
混ぜ合わせることはできません push_branch
、 tag
そしてその pull_request
同じアイテムのフィルター。これは事実上、イベントがコードプッシュイベントとプルリクエスト(またはタグプッシュ)イベントである場合にワークフローを選択する必要があることを意味します。これは単純に不可能です。ソースコードホスティングサービスは、プルリクエスト(マージ前の状態)、タグ、およびコードプッシュイベント用に個別のWebhookを送信します。単一のWebhookイベントが同時にコードプッシュ、タグプッシュ、およびプルリクエストになることはありません。単一のウェブフックは、常に1つのタイプ(コードプッシュ、タグプッシュ、またはプルリクエスト)にのみ関連します。
単一のブランチを構築する
コードプッシュごとに1つのブランチのみをビルドしたいが、他には何もしない場合(他のブランチへのプッシュはビルドをトリガーせず、プルリクエストやタグもトリガーしない)、必要なのは 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
この構成ではワークフローを使用します deploy
すべてのコードプッシュオン master
、およびワークフロー primary
すべてのコードプッシュオン feature/
ブランチし、他のビルドを開始しません。