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
ワークフロー。
パイプライントリガーの構成
自動ビルドトリガーを設定するには、トリガーマップが必要です。トリガーマップは、ビルドをトリガーするコードイベントを定義します。パイプライン構成では、プッシュ、プルリクエスト、タグなどの特定のコードイベントによってトリガーされるパイプラインを指定する必要があります。
ワークフロー エディターを使用したパイプライン トリガーの構成
この例では、YAML でのパイプライン トリガーの構成に重点を置いていますが、ここで説明するように、ワークフロー エディターでパイプライン トリガーを設定することもできます。 ビルドを自動的にトリガーする。
trigger_map: - type: push push_branch: "pipe" pipeline: pipeline-successful
この例では、プロジェクトのリポジトリのパイプブランチへのコードプッシュがトリガーされます。 pipeline-successful
パイプライン。同様の方法で、任意のコード イベントのトリガーを構成できます。コード イベント、ブランチまたはタグ名、およびそれぞれのパイプラインを指定するだけです。
ビルド トリガーで利用可能なすべてのオプションは、次の場所で確認できます。 構成YAMLでのビルドトリガー。
常に実行するようにステージを構成する
デフォルトでは、ワークフローの 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: {}
異なるステージからのアーティファクトの使用
ワークフローでは、前のステージのワークフローによって生成されたアーティファクトを使用する必要がある場合があります。ステップ中にそれらを使用できるようにするには、 アーティファクトプル ステップ。
パイプライン ステージ間で環境変数を共有する
専用のステップを使用して環境変数を共有できます。 パイプライン変数を共有する.詳細については、次を参照してください。 パイプライン ステージ間で環境変数を共有する.
ステージ間で共有するファイルの指定
を使用できます。Bitrise.io へのデプロイ - アプリ、ログ、アーティファクト後続のワークフローで使用するための中間ファイルとして、ファイルとディレクトリをプッシュする手順。そうするために:
-
追加 Bitrise.io へのデプロイ - アプリ、ログ、アーティファクト ビルド アーティファクトを生成するワークフロー (通常はワークフローの最後) に進みます。
steps: ... - deploy-to-bitrise-io@2: {}
-
ステップの構成 パイプライン ステージ間で共有するファイル 下の入力 パイプライン中間ファイル共有 カテゴリー。
を構成しているとき パイプライン ステージ間で共有するファイル 追加する値は、次の構造を使用して、コロンで区切られた項目の改行で区切られたリストである必要があります。
<file_or_directory_path>:<environment_variable_key>
-
file_or_directory_path
: は、後続のステージ ワークフローと共有するファイルまたはディレクトリのローカル ファイル パスです。ディレクトリの共有
ディレクトリは単一のファイルとしてアーカイブおよびアップロードされますが、 パイプライン中間ファイルのプル ステップは、そのようなアーカイブを自動的に抽出します。
-
environment_variable_key
: 特定の項目に割り当てられる環境変数キーです。この環境変数は、アイテムによってダウンロードされた後、アイテムのローカル ファイル パスを保持します。 パイプライン中間ファイルのプル ステップ。環境変数キーの使用
デフォルトの環境変数キーを使用する必要はありません。実際、必要なカスタム環境変数キーを割り当てることができます。
例えば、
"$BITRISE_IPA_PATH:BITRISE_APP_STORE_IPA_PATH"
デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。
たとえば、次のように使用できます。
"BITRISE_TEST_BUNDLE_PATH"
それ以外の"$BITRISE_TEST_BUNDLE_PATH:BITRISE_TEST_BUNDLE_PATH"
例を見てみましょう!
ビルド テスト ファイルを含むディレクトリを共有したい場合 ($BITRISE_TEST_BUNDLE_PATH
) によって生成される xcode-build-for-test
デフォルトのキーと IPA ファイル ($BITRISE_IPA_PATH
) によって生成される xcode-archive
カスタム環境変数キーをステップ実行して割り当てるには、次の構造を使用する必要があります。
steps: ... - deploy-to-bitrise-io@2: inputs: - pipeline_intermediate_files: |- BITRISE_TEST_BUNDLE_PATH $BITRISE_IPA_PATH:BITRISE_APP_STORE_IPA_PATH
プル パイプライン中間ファイルの使用手順
前のステージでワークフローによって生成されたアーティファクトへのアクセスを必要とするワークフローがある場合は、 パイプライン中間ファイルのプル ステップ:
-
追加 パイプライン中間ファイルのプル ワークフローへのステップ (通常、ワークフローの開始時、または共有ファイルに依存するステップの前):
steps: - pull-intermediate-files@1: {}
-
使用
artifact_sources
ステージとワークフローのセットを指定するための入力。入力の構文は次のとおりです。{stage-name}.{workflow-name}
:steps: - pull-intermediate-files@1: inputs: - artifact_sources: stage-1\..*
上記の例では、ステージ内のすべてのワークフローからすべてのアーティファクトを取得しています。
stage-1
.特定のワークフローの設定とワイルドカードの使用
特定のワークフローを設定して、アーティファクトをプルするか、他の方法でワイルドカードを使用できます。
-
stage1.workflow1
- ステージ 1 のワークフロー 1 からアーティファクトを取得します。 -
stage1\..*
- stage1 のワークフローからすべてのアーティファクトを取得します。 -
.*\.workflow1
- すべてのステージからワークフロー 1 の成果物を取得します。 -
.*
- パイプラインで生成されたすべてのアーティファクトを取得します。
-
-
ステップが終了すると、ファイルとディレクトリが Bitrise.io へのデプロイ - アプリ、ログ、アーティファクト ステップが復元されます。
詳細については、 ステップ リポジトリ.
パイプライン ステージ間で環境変数を共有する
から任意の環境変数を再利用できます。 ワークフロー その後で再利用します ステージ を使用して パイプライン変数を共有するステップ.このステップを使用して環境変数を共有しても、 アプリ.
run_if 条件を使用したオプションのワークフロー
簡単に組み合わせることができます パイプライン変数を共有する ステップ run_if
オプションのワークフローでパイプラインを作成するための式。詳細については、こちらをご覧ください パイプラインを使用したオプションのワークフローの run_if 条件の設定.
そうするために:
-
追加 パイプライン変数を共有する ワークフローに進みます。
-
必要に応じて、追加の実行条件を 追加の実行条件 入力。ステップは、ここで指定した条件が真の場合にのみ実行されます。
-
後続のステージで使用する環境変数を パイプライン ステージ間で共有する変数 入力。
環境変数キーの使用
を使用して環境変数を定義できます。
{key}={value}
構文。例えば、MY_ENV_KEY=value
、 またINSTALL_PAGE_URL=$BITRISE_PUBLIC_PAGE_URL
.デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。例えば、
EXISTING_ENV_KEY
.このステップを使用して環境変数を共有しても、 アプリ.
それでおしまい!後続のステージで環境変数を使用できるようになりました!
パイプラインを使用したオプションのワークフローの run_if 条件の設定
オプションのワークフローは パイプライン かどうかを決定できる機能 ワークフロー で設定した条件に基づいて実行するかどうか run_if
表現。
他のパイプライン機能と同様に、この機能は bitrise.yml.
の中に bitrise.yml
、 下 stages/workflows
フィールドに追加できます run_if
任意のワークフローへの式であり、それらがパイプライン ビルドの一部である場合、 run_if
ワークフローを実行するかどうかを決定するために評価されます。
あ run_if
任意の有効な Go テンプレートにすることができます
あ run_if
任意の有効な値にすることができます テンプレートに移動、評価される限り true
また false
(または String 表現のいずれか、たとえば True
、 t
、
yes
また y
すべてとみなされる true
)。テンプレートが次のように評価される場合 true
、ワークフローが実行されます。それ以外の場合は実行されません。
次の例は、run_if 式を設定する方法を示しています。 bitrise.yml
ファイル:
format_version: '11' envs: FOO: 'BAR' pipelines: pipeline1: stages: - stage1: {} stages: stage1: workflows: - workflow-never-run: run_if: '{{ false }}' - workflow-always-run: run_if: '{{ true }}' - workflow-optionally-dont-run: run_if: '{{ getenv "FOO" | eq "notBAR" }}' - workflow-optionally-run: run_if: '{{ getenv "FOO" | eq "BAR" }}' workflows: workflow-never-run: {} workflow-always-run: {} workflow-optionally-dont-run: {} workflow-optionally-run: {}