パイプラインの構築[ベータ版]
Pipelines with stages are the older way of configuring Pipelines. We recommend switching to the new way where you can define Workflow dependencies to create more flexible configurations, and you no longer have to waste time waiting for a stage to finish.
Bitrise Pipelineは、CI/CD構成の最上位レベルです。パイプラインを使用して、CI / CDプロセス全体を整理し、複数の異なるタスクを並行しておよび/または順次実行する高度な構成をセットアップできます。
You can convert a Pipeline with stages into the new format: ステージのあるパイプラインをグラフパイプラインに変換.
パイプラインの構成要素は次のとおりです。
-
手順:スクリプト実行のブロック。それぞれがCI/CDプロセスで単一のタスクを定義します。
-
ワークフロー:ステップのコレクション。アプリのビルドが実行されている場合、ステップはワークフローで定義された順序で実行されます。
-
ステージ:ワークフローのコレクション。ステージには、同じステージですべて並行して実行される複数のワークフローを含めることができます。すべてのワークフローがステージで成功すると、パイプラインは次のステージに進みます。ワークフローのいずれかが失敗した場合、特定のステージを常に実行するように構成しない限り、パイプラインは他のステージを実行せずに終了します。
Bitriseパイプラインの構成
現在、パイプラインの構成は、直接編集することによってのみ可能です。 bitrise.yml ファイル。グラフィカルなワークフローエディターでワークフローを作成および変更できますが、パイプラインとステージをYAML形式で定義する必要があります。
パイプライン、ステップ、およびワークフローの定義
The bitrise.yml
ファイルには、パイプラインの完全な構成が含まれています。すべてのように bitrise.yml
ファイルの場合、最初にフォーマットバージョンとプロジェクトタイプを定義する必要があります。
--- format_version: '8' default_step_lib_source: project_type: android
これは最低限です bitrise.yml
構成。パイプラインを定義するには、パイプライン属性を使用する必要があります。
pipelines: pipeline-successful: stages: - stage-successful-1: {} - stage-successful-2: {} - stage-successful-3: {}
この例では、というパイプラインがあります pipeline-successful
、連続して実行される3つのステージがあります。これは、 stage-successful-1
正常に終了し、 stage-successful-2
開始します。いずれかのステージが失敗した場合、後続のステージは開始されません。代わりに、パイプラインが中止され、失敗としてマークされます。
各ステージは、 stages
属性。ステージの定義とは、ステージの一部であるワークフローを指定することを意味します。
stages: stage-successful-1: workflows: - test-1: {} stage-successful-2: workflows: - build-1: {} - build-2: {} stage-successful-3: workflows: - deploy-1: {} - deploy-2: {}
この例では、ステージは test-1
、 build-1
、 build-2
、 deploy-1
、 と deploy-2
ワークフロー。
常に実行するようにステージを構成する
デフォルトでは、ワークフローの 1 つが失敗したためにステージが失敗した場合、パイプラインの他の後続のステージは実行されません。ただし、パイプラインが中止されない限り、特定のステージを実行するようにパイプラインを構成できます。
これを行うには、設定する必要があります should_always_run
ステージの属性をtrueに設定します。
stages: stage-always-run-successful-1: should_always_run: true workflows: - deploy-1: {} - deploy-2: {}
上記の例では、Stage が呼び出されます。 stage-always-run-successful-1
前のステージのステータスに関係なく、常に実行されます。これらのステージが実行されない唯一の方法は、パイプライン ビルドがユーザーによって中止された場合です。
失敗したステージのワークフローを中止する
デフォルトでは、特定のステージのワークフローに障害が発生しても、同じステージの他のワークフローは自動的に中止されません。これらのワークフローは実行されますが、次のステージは開始されません。ただし、この動作を変更して、同じステージ内の他のすべてのワークフローを即座に自動的に中止することができます。
そのためには、を設定する必要があります abort_on_fail
に属性 true
:
stages: stage-abort-on-fail-1: abort_on_fail: true workflows: - deploy-1: {} - deploy-2: {}
パイプライン ステージ間で環境変数を共有する
から任意の環境変数を再利用できます。 ワークフロー その後で再利用します ステージ を使用して パイプライン変数を共有するステップ.このステップを使用して環境変数を共有しても、 アプリ.
run_if 条件を使用したオプションのワークフロー
簡単に組み合わせることができます パイプライン変数を共有する ステップ run_if
オプションのワークフローでパイプラインを作成するための式。詳細については、こちらをご覧ください パイプラインを使用したオプションのワークフローの run_if 条件の設定.
そうするために:
-
追加 パイプライン変数を共有する ワークフローに進みます。
-
必要に応じて、追加の実行条件を 追加の実行条件 入力。ステップは、ここで指定した条件が真の場合にのみ実行されます。
-
Add the Env Var(s) you would like to use in subsequent Workflows in the Variables to share between Pipeline Workflows input.
環境変数キーの使用
を使用して環境変数を定義できます。
{key}={value}
構文。例えば、MY_ENV_KEY=value
、 またINSTALL_PAGE_URL=$BITRISE_PUBLIC_PAGE_URL
.デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。例えば、
EXISTING_ENV_KEY
.このステップを使用して環境変数を共有しても、 アプリ.
それでおしまい!後続のステージで環境変数を使用できるようになりました!
Bitriseパイプラインの構成
現在、パイプラインの構成は、直接編集することによってのみ可能です。 bitrise.yml ファイル。グラフィカルなワークフローエディターでワークフローを作成および変更できますが、パイプラインとステージをYAML形式で定義する必要があります。
パイプライン、ステップ、およびワークフローの定義
The bitrise.yml
ファイルには、パイプラインの完全な構成が含まれています。すべてのように bitrise.yml
ファイルの場合、最初にフォーマットバージョンとプロジェクトタイプを定義する必要があります。
--- format_version: '8' default_step_lib_source: project_type: android
これは最低限です bitrise.yml
構成。パイプラインを定義するには、パイプライン属性を使用する必要があります。
pipelines: pipeline-successful: stages: - stage-successful-1: {} - stage-successful-2: {} - stage-successful-3: {}
この例では、というパイプラインがあります pipeline-successful
、連続して実行される3つのステージがあります。これは、 stage-successful-1
正常に終了し、 stage-successful-2
開始します。いずれかのステージが失敗した場合、後続のステージは開始されません。代わりに、パイプラインが中止され、失敗としてマークされます。
各ステージは、 stages
属性。ステージの定義とは、ステージの一部であるワークフローを指定することを意味します。
stages: stage-successful-1: workflows: - test-1: {} stage-successful-2: workflows: - build-1: {} - build-2: {} stage-successful-3: workflows: - deploy-1: {} - deploy-2: {}
この例では、ステージは test-1
、 build-1
、 build-2
、 deploy-1
、 と deploy-2
ワークフロー。
常に実行するようにステージを構成する
デフォルトでは、ワークフローの 1 つが失敗したためにステージが失敗した場合、パイプラインの他の後続のステージは実行されません。ただし、パイプラインが中止されない限り、特定のステージを実行するようにパイプラインを構成できます。
これを行うには、設定する必要があります should_always_run
ステージの属性をtrueに設定します。
stages: stage-always-run-successful-1: should_always_run: true workflows: - deploy-1: {} - deploy-2: {}
上記の例では、Stage が呼び出されます。 stage-always-run-successful-1
前のステージのステータスに関係なく、常に実行されます。これらのステージが実行されない唯一の方法は、パイプライン ビルドがユーザーによって中止された場合です。
失敗したステージのワークフローを中止する
デフォルトでは、特定のステージのワークフローに障害が発生しても、同じステージの他のワークフローは自動的に中止されません。これらのワークフローは実行されますが、次のステージは開始されません。ただし、この動作を変更して、同じステージ内の他のすべてのワークフローを即座に自動的に中止することができます。
そのためには、を設定する必要があります abort_on_fail
に属性 true
:
stages: stage-abort-on-fail-1: abort_on_fail: true workflows: - deploy-1: {} - deploy-2: {}
パイプライン ステージ間で環境変数を共有する
から任意の環境変数を再利用できます。 ワークフロー その後で再利用します ステージ を使用して パイプライン変数を共有するステップ.このステップを使用して環境変数を共有しても、 アプリ.
run_if 条件を使用したオプションのワークフロー
簡単に組み合わせることができます パイプライン変数を共有する ステップ run_if
オプションのワークフローでパイプラインを作成するための式。詳細については、こちらをご覧ください パイプラインを使用したオプションのワークフローの run_if 条件の設定.
そうするために:
-
追加 パイプライン変数を共有する ワークフローに進みます。
-
必要に応じて、追加の実行条件を 追加の実行条件 入力。ステップは、ここで指定した条件が真の場合にのみ実行されます。
-
Add the Env Var(s) you would like to use in subsequent Workflows in the Variables to share between Pipeline Workflows input.
環境変数キーの使用
を使用して環境変数を定義できます。
{key}={value}
構文。例えば、MY_ENV_KEY=value
、 またINSTALL_PAGE_URL=$BITRISE_PUBLIC_PAGE_URL
.デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。例えば、
EXISTING_ENV_KEY
.このステップを使用して環境変数を共有しても、 アプリ.
それでおしまい!後続のステージで環境変数を使用できるようになりました!
iOSプラットフォームで現在サポートされているユースケース
一部ご用意しました パイプライン iOS の一般的な使用例に基づいたレシピ。これらには、ユーザーが実行する必要のある最も頻繁なタスクが含まれています。
(iOS)複数のシミュレーターで並行してテストを実行する
説明
この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリ。ユニットテストとUIテストの例がいくつかあり、テストプランを使用してテストをグループ化します。
The パイプライン構成の例 プロジェクトのすべてのテストケースをさまざまなiOSシミュレーターで実行する方法を紹介します。
run_tests_on_simulators
パイプラインは2つのステージを順番に実行します。
-
build_tests stage
を実行しますbuild_tests
ワークフロー。このワークフローgitは、サンプルプロジェクトのクローンを作成し、xcode-build-for-test
ターゲットと関連するテストを構築する手順。構築されたテストバンドルは次のステージに転送されます(run_tests_on_simulators
)経由deploy-to-bitrise-io
ステップ。ビルドテストバンドルは圧縮されています
xcode-build-for-test
ステップは、ビルドされたテストバンドルを圧縮し、生成されたzipを$BITRISE_DEPLOY_DIR
。そのディレクトリのコンテンツは、デフォルトでワークフローアーティファクトにデプロイされます。deploy-to-bitrise-io
ステップ。アーティファクト ファイルのサイズ制限
デプロイするファイルの数に制限はありません アーティファクト ビルドごと。ただし、ファイルサイズには制限があり、1 ファイルあたり 2GB です。
-
run_tests_on_simulators
Stageは、3つのワークフローを並行して実行します。run_tests_iPad
、run_tests_iPhone
、 とrun_tests_iPod
。これらのワークフローは両方とも、新しいワークフローを使用しますxcode-test-without-building
前のステージで構築されたテストバンドルに基づいてテストを実行するステップ。事前に構築されたテストバンドルは、_pull_test_bundle
ユーティリティワークフロー。
指示
新しいBitriseサンプルプロジェクトで構成をテストするには、次の手順を実行します。
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主人
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
提供されている配布方法のいずれかを選択します(たとえば、
、現在はテストに重点を置いているため、実際には問題ではありません)。 -
提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動します bitrise.yml タブを押して、既存のものを置き換えます
bitrise.yml
例の内容でbitrise.yml
ファイル。 -
クリック ワークフロー、パイプラインポップアップの下部にある「」ドロップダウンメニュー。
ボタンをクリックし、 「
bitrise.yml
(iOS)テストグループを並行して実行する
説明
この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリ。ユニットテストとUIテストの例がいくつかあり、テストプランを使用してテストをグループ化します。
XCodeテストプラン
Xcodeテストプランは、さまざまなテスト構成で一連のテストを実行する方法を提供します。 raywenderlich.comには素晴らしい Xcodeテストプランの開始方法に関するチュートリアル。
パイプライン構成の例は、さまざまなテストグループを並行して実行する方法を示しています。
run_tests_groups
パイプラインは2つのステージを順番に実行します。
-
build_tests
を実行するステージbuild_tests
ワークフロー。このワークフローgitは、サンプルプロジェクトのクローンを作成し、xcode-build-for-test
ターゲットと関連するテストを構築する手順。構築されたテストバンドルは次のステージに転送されます(run_tests_groups
)経由deploy-to-bitrise-io
ステップ。 -
run_tests_groups
Stageは、2つのワークフローを並行して実行します。run_ui_tests
とrun_unit_tests
。これらのワークフローは両方とも新しいxを使用しますcode-test-without-building
前のステージで構築されたテストバンドルに基づいてテストを実行するステップ。事前に構築されたテストバンドルは、_pull_test_bundle
ユーティリティワークフロー。
指示
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主人
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
提供されている配布方法のいずれかを選択します(たとえば、
、現在はテストに重点を置いているため、実際には問題ではありません)。 -
提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動します bitrise.yml タブを押して、既存のものを置き換えます
bitrise.yml
例の内容でbitrise.yml
ファイル。 -
クリック
ボタンをクリックし、run_tests_groups
「ワークフロー、パイプラインポップアップの下部にある「」ドロップダウンメニュー。
bitrise.yml
(iOS)テスト結果のマージとテストレポートアドオンへのデプロイ
説明
Test Reportsアドオンは、Bitriseビルドに関連付けられています。異なるビルドで生成されたすべてのテストレポートをアドオンの単一のページに表示するには、レポートをマージして追加のビルドにデプロイする必要があります。
この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリと拡張'iOSテストグループを並行して実行する'テスト結果をマージおよびデプロイするパイプライン構成の例。
run_ui_tests
と run_unit_tests
ワークフローは、deploy-to-bitrise-ioステップで拡張され、生成されたテスト結果を次のステージで利用できるようにします。
run_tests_groups
パイプラインは新しいステージで拡張されます: deploy_test_results
。このステージは、 deploy_test_results
ワークフロー:
-
artifact-pull
ステップは、ステージによって以前に生成されたすべてのzip形式のテスト結果をダウンロードします。run_tests_groups
。 -
script
ステップは、各テスト結果をテストレポートアドオンデプロイディレクトリ内の新しいテスト実行ディレクトリに解凍し、関連するものを作成しますtest-info.json
ファイル。 -
deploy-to-bitrise-io
ステップは、マージされたテスト結果をデプロイします。
指示
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主人
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
提供されている配布方法のいずれかを選択します(たとえば、
、現在はテストに重点を置いているため、実際には問題ではありません)。 -
提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動します bitrise.yml タブを押して、既存のものを置き換えます
bitrise.yml
拡張された例の内容で bitrise.yml ファイル。 -
クリック
ボタンをクリックし、 「 ポップアップの下部にある「」ドロップダウンメニュー。 -
パイプラインのビルドページを開きます。
-
を選択 deploy_test_results 建てる。
-
クリック
ビルドの詳細ページで、 マージされたテストレポートを表示します。
bitrise.yml
Androidプラットフォームで現在サポートされているユースケース
一部ご用意しました パイプライン 一般的な Android の使用例に基づいたレシピ。これらには、ユーザーが実行する必要がある最も頻繁なタスクが含まれています。例には全体が含まれます ワークフロー ほとんどの場合、コピーして貼り付けることができます。
(Android)複数のデバイスまたはシャードでUIテストを並行して実行する
説明
パイプラインを利用した並列ワークフローで単一モジュールのUI(インストルメンテーション)テストを実行します。シャードまたはデバイスごとにテストを並行して実行できます。
パイプラインには、シリアルに実行される2つのステージが含まれています。
-
build_for_ui_testing
:このステージはワークフローを実行します—名前も付けられますbuild_for_ui_testing
—それはandroid-build-for-ui-testing
テストで使用するAPKを作成し、deploy-to-bitrise-io
後のステージで使用するためにそれらのAPKを保存するステップ。このステージを実際のテストとは別に実行すると、各テストステージで、テストステージごとに再構築するのではなく、これらの事前に作成されたAPKを使用できます。 -
run_ui_tests_on_devices
:このステージでは、3つのUIテストワークフローを並行して実行します—ui_test_on_phone
、ui_test_on_tablet
、ui_test_on_foldable
—を使用するandroid-instrumented-test
特定のデバイスタイプごとに、前のワークフローで構築されたAPKでUIテストを実行する手順。
指示
新しいBitriseサンプルプロジェクトでこの構成をテストするには、次の手順を実行します。
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主要
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
入る
アプリ
指定されたモジュールとして。 -
入る
デバッグ
指定されたバリアントとして。 -
通常どおりプロンプトを続行します—変更は必要ありません。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動します bitrise.yml タブをクリックし、既存のyamlの内容を例の内容に置き換えます
bitrise.yml
。 -
クリック
ボタンをクリックし、ui_test_on_multiple_devices
のオプション ポップアップの下部にあるドロップダウンメニュー。
bitrise.yml
(Android)ユニットテストとUIテストを並行して実行する
説明
パイプラインを利用して、単体テストとUIテストを並行して実行します。
このパイプラインには1つのステージが含まれています— stage_unit_and_ui_test
—2つのワークフローを並行して実行します。
-
unit_tests
:このワークフローは、指定されたモジュールとバリアントの単体テストを、android-unit-test
ステップ。 -
ui_tests
:このワークフローは、指定されたモジュールとバリアントを使用してビルドしますandroid-build-for-ui-testing
ステップ、を使用してエミュレータを起動しますavd-manager
ステップ、エミュレータを使用して起動するのを待ちますwait-for-android-emulator
ステップ、およびを使用してUIテストを実行しますandroid-instrumented-test
ステップ。
指示
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主要
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
入る
アプリ
指定されたモジュールとして。 -
入る
デバッグ
指定されたバリアントとして。 -
通常どおりプロンプトを続行します—変更は必要ありません。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動しますbitrise.ymlタブをクリックし、既存のyamlの内容を例の内容に置き換えます
bitrise.yml
。 -
クリック
ボタンをクリックし、pipeline_unit_and_ui_test
のオプション ポップアップの下部にあるドロップダウンメニュー。
bitrise.yml
(Android)モジュールごとのユニットテストシャーディング
説明
パイプラインを利用した並列ワークフローで、モジュール化されたアプリの単体テストを実行します。
このパイプラインには、2つのワークフローを並行して実行する1つのステージ(stage_unit_test)が含まれています。
-
unit_test_app
:このワークフローは、を使用してアプリモジュールの単体テストを実行しますandroid-unit-test
ステップ。 -
unit_test_library
:このワークフローは、の単体テストを実行しますlib-example
モジュールを使用してandroid-unit-test
ステップ。
指示
-
訪問 新しいアプリページを作成する 新しいアプリを作成します。
-
gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(
https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git
) の中に Gitリポジトリ(クローン)URL 分野。 -
表示されるポップアップで、これがパブリックリポジトリであることを確認します。
-
を選択
主要
スキャンするブランチ。 -
プロジェクトスキャナーが完了するのを待ちます。
-
入る
アプリ
指定されたモジュールとして。 -
入る
デバッグ
指定されたバリアントとして。 -
通常どおりプロンプトを続行します—変更は必要ありません。
-
新しいBitriseプロジェクトのワークフローエディタを開きます。
-
に移動しますbitrise.yml タブをクリックし、既存のyamlの内容を例の内容に置き換えます
bitrise.yml
。 -
クリック
ボタンをクリックし、を選択しますpipeline_unit_test
のオプション ポップアップの下部にあるドロップダウンメニュー。