ビルドトリガーについて

概要

ビルドトリガーを使用して、1つまたは複数のBitriseビルドを自動的に開始します。トリガーの定義には、コードイベントと、ビルドをトリガーするためにイベントが一致しなければならない条件が 1 つ以上含まれています

ビルドトリガーを使用して、1 つ以上の Bitrise ビルドを自動的に開始します。トリガーの定義には、コードイベントと、ビルドをトリガーするためにイベントが一致する必要がある 1 つ以上の条件が含まれます。

ワークフローまたはパイプライン内でトリガーを定義できます。トリガーを使用すると、単一のコードイベントで複数の異なるワークフローまたはパイプラインをトリガーできるため、すべてを単一のワークフローまたはパイプラインにバンドルすることなく、コード変更の範囲に基づいて CI プロセスの関連部分をすべて一緒に実行できます。各ビルドは独立して実行され、個別の結果を提供します。

トリガーの詳細な構文と正確なトリガー条件については、ビルドトリガーの YAML 構文。

コードイベント

ビルドをトリガーするには、次の 3 種類のコードイベントを使用できます。

コードプッシュ: トリガー条件に一致するコミットを使用してコードをプッシュするたびに、ビルドを自動的にトリガーします。たとえば、プロジェクトのリポジトリの指定されたブランチへのコミットによってビルドがトリガーされます。
プルリクエスト: プルリクエストがトリガー条件に一致するたびに、ビルドを自動的にトリガーします。たとえば、プルリクエストによってビルドがトリガーされるソースブランチや宛先ブランチを指定できます。

初回のPRイベント

プルリクエストは、最初のイベントで 1 回だけビルドをトリガーします。ほとんどの場合、その初期イベントはプルリクエストの作成です。たとえば、PR をドラフト PR に変換しても、別のビルドはトリガーされません。プルリクエストの更新用にビルドをトリガーするには、新しいコミットのコードプッシュトリガーを設定します
Gitタグ: 特定のタグを持つコミットがビルドをトリガーするたびに、ビルドを自動的にトリガーします。

条件

トリガー条件はコードイベントのフィルターです。すべてのプルリクエストでビルドをトリガーする代わりに、特定のブランチを対象とするプルリクエストのトリガーを構成できます。

Gitプロバイダによってサポートされる条件は異なります。完全な表については、サポートされているトリガー条件。

トリガー条件は、単一のトリガー内で組み合わせることができます。たとえば、PR が特定のブランチを対象とし、かつ特定のラベルが含まれている場合にのみビルドをトリガーするプルリクエストトリガーを設定できます。

トリガー優先度

トリガーには優先度設定を割り当てることができます。これにより、特定のトリガーによってトリガーされるビルドの優先度が決まります。優先度が高いほど、ビルド・キュー内のビルドの位置も高くなります。

優先度は、ワークフローエディターまたはプロジェクトの設定 YAML ファイルのいずれかで割り当てることができます。優先度は常に -100～100 の間の整数です。数値が大きいほど優先度が高くなります。デフォルトの優先度は 0 です

ビルドの優先順位、およびさまざまなタイプの優先度間の優先順位の詳細については、以下をご覧ください。ビルドの優先順位。

トリガー変数

ビルドトリガーに関連する多くの環境変数は、自動的にトリガーされるビルド中に使用できます。これらの変数は、ビルドトリガーとプルリクエスト属性に関する詳細なコンテキストを提供します。これらのトリガー変数は次の目的で使用します。

コメント、ラベル、変更されたファイルなどのプルリクエストデータを使用して、複雑なワークフローと意思決定プロセスを自動化します。
誰がどのようにビルドをトリガーするのかを理解し、それを活用してワークフローのデバッグに役立てましょう
正確なビルド条件を実装して不要な実行を減らし、時間とリソースを節約します。

すべてのトリガー変数とその定義は、参照表に記載されています。表74「bitrise.ioによって公開された環境変数」.

トリガー変数は、要件が満たされている場合にのみ使用できます。たとえば、 BITRISE_GIT_PULL_REQUEST_COMMENT 変数を使用できるのは、ビルドが PR コメントによってトリガーされた場合だけです。つまり、ビルドトリガーに PR コメントがある場合だけです。 pr_comment 条件。正確な条件は、以下で確認できます表74「bitrise.ioによって公開された環境変数」。

トリガー変数のユースケース

トリガー変数の使用例をいくつか示します。これらはあくまで提案に過ぎません。変数をいろいろ試して、ニーズに最適なものを見つけてください

例 29. PRコメントへの報告

BITRISE_GIT_PULL_REQUEST_COMMENT_ID: プルリクエストのコメント ID を使用して、プルリクエストの元のコメントにステータス更新を直接投稿します。これには、成功、失敗、ログ、その他の関連情報などの詳細を含めることができます。

例 30. 条件付きテストの実行

BITRISE_GIT_CHANGED_FILES : コードベースの変更された部分を特定し、その変更に基づいて、UI 変更のフロントエンドテストや API 変更のバックエンドテストの実行など、特定のテストスイートを起動します。

例 31. コミットメッセージまたはラベルに基づくさまざまな環境へのデプロイ

使用 BITRISE_GIT_COMMIT_MESSAGES そして BITRISE_GIT_PULL_REQUEST_LABELS デプロイ環境を決定するため。たとえば、コミットメッセージに「[staging]」が含まれていたり、「ready-for-staging」というラベルが表示されている場合は、コードをステージング環境にデプロイします

マージキューのサポート

GitHub マージキューを使うと、複数のプルリクエスト (PR) を 1 つのブランチに自動的にマージできます。Bitrise ビルドで各 PR の変更を確認するには、以下のようにトリガーを設定します gh-readonly-queue/* ブランチフィルターとして。このプレフィックスについて詳しくは、 GitHub ドキュメンテーション。

マージキューは、キューに対してトリガーされたビルドが PR ビルドと同じステータス名を報告する場合にのみ正しく機能します。

たとえば、以下の構成では、マージキューからマージされたすべてのブランチが、次のコードでビルドをトリガーします。 ci-pipeline パイプライン:

pipelines:
  ci-pipeline:
    triggers:
      push:
      - branch: "gh-readonly-queue/*"
    status_report_name: ci/bitrise/<project_slug>/pr

このセクションの内容: