設定 YAML リファレンス

Required: A configuration YAML file is invalid without it.

Bitriseコンフィグレーションフォーマットのバージョン。

Bitrise CLIはそれをチェックして、設定ファイルとCLIバージョン間の互換性を確認します。これはローカルで実行されるビルドに関係します。Bitrise ウェブサイトでは CLI は常に最新なので、 format_version プロパティはトリガーされたビルドには影響しません。

format_version: '25'

設定で使用されるステップのデフォルトステップライブラリ。Bitriseは、特定のステップに特定のソースが提供されていない場合にこのソースを使用します

デフォルト値は https://github.com/bitrise-io/bitrise-steplib.git。このリポジトリの独自のフォークを Step ソースとして使用することも、Steps を参照してその正確なソースリポジトリを含めることもできます。 ステップリファレンス/ IDフォーマット.

default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git

Bitriseプロジェクトのタイプ (例: ios、 android、 flutterなど。

プロジェクトタイプはいつでも変更できますが、初期設定後は関係ありません。

default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git

Bitriseコンフィグのタイトルです。

title: My Bitrise project

Bitriseのコンフィグレーションの簡単なまとめです。

summary: This project runs tests for my app.

Bitriseのコンフィグレーションの詳細な説明です。

description: This project runs unit and UI tests when a pull request is opened to the dev branch.

Steps が Linux ホスト上のサービスコンテナとして使用する Docker コンテナ定義。

ステップのグループに1つ以上のサービスを設定できるため、Dockerコンテナを高度な統合テスト用のサービスとして実行できます。これらは、のライフサイクルと結びついていますwithグループ化してバックグラウンドで一緒に実行します。グループ内のすべてのステップが終了すると、クリーンアップされます。

以下を定義する必要があります。

もっと読む: サービスコンテナ。

services:
 postgres:
   image: postgres:16
   envs: 
   - POSTGRES_USER: postgres
   - POSTGRES_DB: bitrise 
   ports:
   - 5432:5432 
   options: >-
     --health-cmd pg_isready
     --health-interval 10s
     --health-timeout 5s
     --health-retries 5
 redis: 
   image: redis:7
     ports: - 6379:6379
     options: >-
     --health-cmd "redis-cli ping"
     --health-interval 10s
     --health-timeout 5s
     --health-retries 5

Steps が実行コンテナとして使用する Docker コンテナ定義。

Dockerコンテナは、設定YAMLファイルで任意のBitriseプロジェクト用に定義できます。設定ファイルの最上位でコンテナを定義し、それをで参照しますwith ワークフロー設定内のグループ。以下を定義する必要があります

もっと読む: ステップ実行コンテナ。

containers:
  node-21:
    image: node:21.6

このプロパティには、次のようなプロジェクトレベルの設定情報が含まれます。 環境変数。

ビルドスタックなどのメタ情報はここには属しませんが、 meta プロパティ。

app:
  envs:
  - TEST: '' 
    opts:
      is_expand: false

Bitrise設定に関連するプロジェクトメタデータのキーと値のペアを保存します。最も重要なのは、プロジェクトのデフォルトスタックとビルドマシンタイプを定義することです

もっと読む: bitrise.ymlファイルでスタックを設定する。

meta:
  bitrise.io:
    stack: linux-docker-android-22.04
    machine_type_id: g2.linux.2medium

プロジェクトレベルでビルドトリガーを定義します。これは従来のトリガー設定方法です。代わりに、パイプラインまたはワークフロー内で定義したターゲットベースのトリガーを使用することをおすすめします

もっと読む: 従来のプロジェクトベースのトリガー。

trigger_map:
- pull_request_source_branch: "*"
  type: pull_request
  workflow: primary

プロジェクトの設定でパイプラインを定義します。パイプラインを使用すると、CI/CD プロセス全体を整理したり、複数の異なるタスクを並行して実行したり、順次実行したりする高度な設定を行うことができます

pipelines リファレンス: パイプラインレベルのプロパティ。

もっと読む: パイプライン。

pipelines:
  test:
  title: Test Pipeline
  summary: This Pipeline runs unit tests.
  workflows:
    primary: {}

設定に含まれるワークフロー。ワークフローは、再利用可能で設定可能な作業単位であるステップの集まりです。ステップはワークフロー内で順番に実行されます

workflows リファレンス: ワークフローレベルのプロパティ。

workflows: 
  primary:
    steps: 
    - script: {}

ステップバンドルを使用すると、複数のステップを 1 つのユニットにまとめることができます。ステップバンドルを使うと、ステップとステップのシーケンスを再利用できます

ステップバンドルはどのワークフローにも挿入できます。ユーティリティワークフローやワークフローチェーンとは異なり、ステップバンドルはワークフローのどこにでも配置できます

もっと読む: ステップバンドル。

step_bundles:
  primary:
    steps:
    - git-clone: {}
    - restore-cache: {}

ザル include プロパティを使うと、Bitriseの設定で他の設定YAMLファイルを使用して、大きくて複雑なYAMLファイルを小さなモジュール型のコンポーネントに分解できます。

モジュール型 YAML 設定には以下が含まれます。

もっと読む: モジュラーYAML構成。

include:
  - path: path/to/config_module.yml

セットアップするツールバージョン。バージョン構文は以下をサポートします。

もっと読む: ツールバージョンの設定。

tools:
  nodejs: 22:installed
  ruby: 3.3:latest

パイプラインのタイトル。

これはパイプラインの ID とは異なります。ID はパイプラインの作成時に設定します。ID とは異なり、タイトルは一意である必要はありません。のワークフローエディタ UI に表示されます。 パイプライン セクション:パイプラインセレクタードロップダウンメニューを開いた場合。

pipelines:
  test:
    title: Test pipeline

パイプラインの簡単な要約。オプション。

pipelines:
  test:
    summary: This Pipeline runs unit tests.

パイプラインの詳細な説明。オプション。

pipelines:
  test:
    description: 'This Pipeline runs unit tests in parallel, using test sharding.'

パイプライン用に定義されたターゲットベースのトリガー:コードイベントがトリガーで定義された条件と一致すると、Bitriseはパイプラインでビルドをトリガーします。

の詳細な構文については triggers プロパティと使用可能なオプション、チェックアウト:

もっと読む: ビルドトリガーの YAML 構文。

pipelines:
  test:
    triggers:
      push:
      - branch: main

ビルドが完了した後に接続サービス (GitHub、GitLab、Bitbucket など) に送信されるステータスレポートに表示される名前。

静的値と動的値の両方を持つことも、2つのタイプを組み合わせることもできます。

サポートされている文字と変数:

pipelines:
  test:
    status_report_name: ci/bitrise/510526/push

パイプライン設定の一部であるワークフロー。

を使用してワークフロー間の依存関係を作成できます depends_on プロパティ。

pipelines:
  test:
    workflows:
      primary:

優先度設定は、ビルドキュー内の Pipeline ビルドの位置を決定します。優先度が高いほど、Pipeline ビルドは早く実行されます。

サポートされている値:

もっと読む:

pipelines:
  test:
    priority: 10

このプロパティは、このワークフローが依存するワークフローを定義します。リスト内のいずれかのワークフローが失敗すると、このワークフローは実行されません。

依存するワークフローのリストには、ブロックシーケンスとフローシーケンスの両方のタイプの YAML 配列構文を使用できます。依存関係リストに表示されるすべてのワークフローは、同じパイプラインの一部である必要があります。

サポートされている値: YAML 配列構文のワークフロー名。

もっと読む: Creating a Pipeline。

pipelines:
  example:
    workflows:
      A: {}
      B:
        depends_on:
        - A
      C:
        depends_on:
        - A
      D:
        depends_on:
        - B
        - C

D:
  depends_on: [B, C]

このプロパティが true、このワークフローが失敗すると、パイプラインとその他の実行中のワークフローは中止されます。

サポートされている値: ブーリアン

もっと読む: ワークフロー障害時のパイプラインの中止。

pipelines:
  example:
    workflows:
      A: {}
      B:
        abort_on_fail: true

このプロパティは、以前のワークフローが失敗した場合にワークフローを実行するかどうかを定義します。

推移的な依存関係に注意してください。常に実行するように設定されているワークフローに、失敗した親ワークフローがあっても、そのワークフローは引き続き実行されます。ただし、それに依存するワークフローは実行されません。例えば、ワークフロー C がワークフロー B に依存しているとします。ワークフロー B はワークフロー A に依存しているとします。3 つのワークフローのうち、常に実行するように設定されているのは B だけです。

サポートされている値:

もっと読む: 常にパイプラインでワークフローを実行する

pipelines:
  example:
    workflows:
      A: {}
      B:
        depends_on: [ A ]
        should_always_run: workflow
      C:
        depends_on: [ B ]
      D:
        depends_on: [ C ]
        should_always_run: workflow

ワークフローを実行するための条件を定義する Go テンプレート式。

プロパティには以下が必要ですexpression3 つの補助関数を含む Go テンプレートを含むフィールド:

Bitrise CLIは実行時にエクスプレッションを評価します。以下の理由でワークフローがスキップされた場合 run_if expression を指定すると、成功したワークフローとしてカウントされるので、その従属ワークフローが実行されます。

もっと読む: run_if 式の例。

pipelines:
  example:
    workflows:
      A: {}
      B:
        run_if:
          expression: {{ enveq "EXAMPLE_KEY" "example value" }}
        depends_on: [A]

ザル parallel プロパティを使用すると、同じワークフローのコピーを 1 つの命令で並行して実行できます。これはテストシャーディングに特に役立ちます

このプロパティは、並行して実行されるコピーの数を決定します。各コピーには次の 2 つの新しい環境変数が割り当てられます。

サポートされている値: 整数。

もっと読む: パイプラインの並列処理。

ワークフローのタイトル。

ワークフローエディターの UI に表示されます。

workflows:
  primary:
    title: Primary Workflow

ワークフローの簡単な要約。

workflows:
  primary:
    summary: This Workflow runs unit tests.

ワークフローの詳細な説明。

workflows:
  primary:
    description: This Workflow runs unit tests with test sharding, and exports the test results to the test reports page. 

ワークフロー用に定義されたターゲットベースのトリガー：コードイベントがトリガーで定義された条件と一致すると、Bitriseはワークフローでビルドをトリガーします。

各トリガーは、コードイベントと少なくとも 1 つの条件を定義します。1 つのトリガーで複数の条件を定義する場合、ビルドをトリガーするにはそれらすべてが一致する必要があります。

の詳細な構文については triggers プロパティと使用可能なオプション、チェックアウト:

もっと読む: ビルドトリガーの YAML 構文。

workflows:
  primary:
    triggers:
      push:
      - branch: main
      pull_request:
      - source_branch: "*"

ビルドが完了した後に接続サービス (GitHub、GitLab、Bitbucket など) に送信されるステータスレポートに表示される名前。

静的値と動的値の両方を持つことも、2つのタイプを組み合わせることもできます。

サポートされている文字と変数:

workflows:
  test:
    status_report_name: ci/bitrise/510526/push

このワークフローが開始される前に実行されるワークフロー。

このプロパティを使用して after_run ワークフローのチェーンを作成します。

もっと読む: ワークフローを連鎖させる。

workflows:
  test:
    steps:
    # test Steps

  deploy:
    before_run:
    - test
    steps:
    # deploy Steps

このワークフローが正常に終了した後に実行されるワークフロー。

このプロパティを使用して before_run ワークフローのチェーンを作成します。

もっと読む: ワークフローを連鎖させる。

workflows:
  deploy:
    steps:
    # deploy Steps

  ci:
    after_run:
    - deploy
    steps:
    # CI Steps

ワークフロー用に定義された環境変数。

各環境変数はキーと値のペアです。環境変数は他の環境変数を値として使用できます EnvVarの値でのEnvVarの使用.

これらの変数は、選択したワークフローでのみ使用できます。同じ設定 YAML ファイルで定義されている他のワークフローはこれらにアクセスできません。プロジェクトレベルの環境変数の方が優先度が高い。 環境変数の可用性の順序.

もっと読む: 環境変数。

workflows:
  primary:
    envs:
    - TEST: test
    - ENV_LABEL: dev
      opts:
        is_expand: false

ワークフローのステップのリスト。

The basic syntax of a Step reference is: <step_lib_source>::<step-id>@<version>:. The Step ID is always required; the source and the version are optional.

もっと読む:

workflows:
    steps:
    - script: {}

workflows:
    steps:
    - https://github.com/bitrise-io/bitrise-steplib.git::script@1: {}

優先度設定は、ビルド・キュー内のワークフロー・ビルドの位置を決定します。優先度が高いほど、ワークフロー・ビルドの実行が早くなります。

サポートされている値: -100 から 100 までの整数。

もっと読む: ビルドの優先順位。

workflows:
  primary:
    priority: 10

ビルドで使用されるツールバージョンの宣言型構成。

特定のワークフローのツールバージョンを定義できます。ツールプロパティを設定の最上位レベルで定義する代わりに、1 つ以上のワークフローの下にネストします。

バージョン構文は以下をサポートします。

もっと読む: ツールバージョンの設定。

workflows:
  primary:
    tools:
      nodejs: 22:installed

プロジェクトメタデータのキーと値のペアを格納します。最も重要なのは、ワークフローのスタックとマシンタイプを定義することです。

もっと読む: bitrise.ymlファイルでスタックを設定する。

workflows:
  deploy:  
    meta:      
      bitrise.io:       
        stack: linux-docker-android-22.04
        machine_type_id: g2.linux.2medium

ステップのタイトル。

これがワークフローエディターに表示され、ステップ ID の代わりになります。

workflows:
    steps:
    - script@1:
        title: Test sharding script

ステップの簡単な要約。

workflows:
    steps:
    - script@1:
        summary: Custom script for sharding.

ステップの詳細な説明。

workflows:
    steps:
    - script@1:
        summary: A custom script for setting up test sharding for Flutter unit tests. 

このプロパティが true の場合、ワークフローの前のステップが失敗した場合でも、そのステップは常に実行されます。

デフォルトでは、ワークフローで前のステップが失敗すると、後続のステップは実行されません。このプロパティが次のように設定されている場合のみ、ステップは実行されます true。

サポートされている値: ブーリアン

もっと読む: 手順をスキップする。

workflows:
  primary:
    steps:
    - script:
        is_always_run: true

このプロパティが true の場合、このステップが失敗してもビルドは失敗しません。

デフォルトでは、あるステップが失敗すると、後続のステップは実行されません。最初に失敗したステップでこのプロパティが次のように設定されている場合 trueビルドが失敗することはありません。以降のステップは引き続き実行され、ビルドは正常に終了できます。

サポートされている値: ブーリアン

workflows:
  primary:
    steps:
    - script:
        is_skippable: true

このプロパティは、ステップを実行するための条件を設定します。有効な Go テンプレート式が必要です。

Arun_if評価結果が true または false (または String 表現のどれか) であれば、どの有効な Go テンプレートでもかまいません (たとえば、True、t、yesまたはyすべて真とみなされます)。テンプレートが次のように評価された場合true、ステップは実行され、そうでない場合は実行されません。

もっと読む:

run_if: |-
        {{enveq "CUSTOM_ENV_VAR_KEY" "test value to test against"}}

このプロパティはステップの時間制限を定義します。ステップが定義された時間より長く実行された場合、ステップは失敗します。制限は秒単位で定義します。

これは、たとえば、すぐにはわからない理由でビルドがハングする場合に便利です。問題の原因であると疑われる 1 つまたは複数のステップにタイムアウトを設定できます。

もっと読む: ステップの制限時間を設定する。

- xcode-test:
     timeout: 120

このプロパティはステップの時間制限を定義します。出力を生成せずにステップが定義された時間より長く実行された場合、ステップは失敗します。制限は秒単位で定義します。

もっと読む: 出力なしでぶら下がっているステップの検出と中止。

  output_slows_down:
    steps:
    - script:
        no_output_timeout: 12

ステップに定義された入力:これらは、ステップがワークフローに追加されるときに設定できる値です。

ステップ入力構文はKEY: valueペア。

もっと読む: ステップ入力リファレンス。

inputs:
- my_key_for_the_env: "default value"

ステップに定義された出力:これらはステップが実行中に設定できる値で、ワークフローの他のステップで使用できます。

ステップのデフォルト出力は、bitrise.ioのワークフローエディターまたは以下で確認できます。step.ymlステップのファイル。ステップ出力は以下で定義できます。step.yml設定によるプロジェクトのファイルoutputs属性。ステップアウト構文は主に a の 2 つの部分から構成されます。KEY: valueペアとoptsフィールド。キーと値は必須です。optsフィールドはオプションです。

もっと読む: ステップ出力リファレンス。

workflows:
  primary:
  steps:
  - gradle-runner:
      outputs:
      - BITRISE_APK_PATH: ALIAS_APK_PATH

このプロパティは、定義済みのトリガーがアクティブかどうかを決定します。デフォルト値は true。トリガーを無効にする場合は、次のように設定します false。

サポートされている値: ブーリアン

workflows:
  primary:
    triggers:
      enabled: false

コードプッシュトリガーは、コードがプロジェクトのリポジトリにプッシュされたときにBitriseビルドをトリガーする条件を定義します。

たとえば、プロジェクトのリポジトリの指定されたブランチにコミットすると、ビルドがトリガーされます。

workflows:
  primary:
    triggers:
      push:
      - branch: main

workflows:
  primary:
    triggers:
      push:
      - branch: main

primary
  triggers:
    push:
    - commit_message:
        regex: '.*\[workflow: deploy\].*'

primary
  triggers:
    push:
    - changed_files: 
        pattern: "myfile.txt"

プルリクエストトリガー:プロジェクトのリポジトリでプルリクエストが開かれたときにBitriseビルドをトリガーする条件を定義します。

primary
  triggers:
    pull_request:
    - source_branch: *

primary
  triggers:
    pull_request:
    - source_branch: main

primary
  triggers:
    pull_request:
    - target_branch: main

primary
  triggers:
    pull_request:
    - label: bugfix

primary
  triggers:
    pull_request:
    - draft_enabled: false

primary
  triggers:
    pull_request:
    - comment: approved

primary
  triggers:
    pull_request:
    - commit_message: "fix for issue"

primary
  triggers:
    pull_request:
    - changed_files: ./path/to/file

Gitタグトリガーは、GitタグがプロジェクトのリポジトリにプッシュされたときにBitriseビルドをトリガーする条件を定義します。

primary
  triggers:
    tag:
    - name: *

primary
  triggers:
    tag:
    - name: 1.0