トリガーマップを使用してビルドをトリガーする

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/ ブランチし、他のビルドを開始しません。

: