Skip to main content

モジュラーYAML構成

概要

モジュラー YAML 構成を使用すると、大規模で複雑な YAML ファイルを、より小さなモジュラー コンポーネントに分割できます。これにより、複数のリポジトリ間での再利用が容易になります。

エンタープライズのみ

モジュラーYAML構成は、エンタープライズプランのワークスペースでのみ利用可能です。また、 設定ファイルを独自のリポジトリに保存する、bitrise.io にはありません。

エンタープライズプランをご利用でないが、モジュラーYAMLに興味がある場合は、 お問い合わせ

モジュラー YAML 構成を使用すると、大規模で複雑な YAML ファイルを、より小さなモジュール コンポーネントに分割できます。これにより、複数のリポジトリ間での再利用が容易になります。YAML ファイルをモジュール化することで、構成をすばやく見つけて更新できるため、エラーやマージの競合のリスクが軽減されます。

モジュール式 YAML 構成には以下が含まれます。

  • bitrise.yml リポジトリのルートにあるファイル。

  • 同じまたは別のリポジトリ内の他の YAML ファイル。別のリポジトリのファイルを含めるには、リポジトリがプライマリ リポジトリと同じ Git アカウントまたは組織に属している必要があります。

  • 1つ以上 include キーワード bitrise.yml ファイル。これらは他の YAML ファイルを参照し、その構成をメイン プロジェクト構成に取り込みます。

追加のYAMLファイルが bitrise.yml ファイルを使用すると、構成内の他のワークフローまたはパイプラインと同様に、そのワークフローまたはパイプラインのいずれかを参照できます。

複数のYAMLファイルからの設定を含める

モジュール構成を作成するには、次の手順が必要です。

  1. 保管する bitrise.yml リポジトリ内のファイル。

  2. さらにYAMLファイルを作成する bitrise.yml リポジトリにコミットします。

ファイル制限

ファイルごとに最大10個のインクルードが可能で、ルートレベルを含めて合計20個の設定ファイルを持つことができます。 bitries.yml ファイル。

bitrise.yml、これらの追加のYAMLファイルを設定に含めることができます。 include キーワード。1 つのパラメータが必要です: path、これは含める YAML ファイルの場所です。

指定するパスはリポジトリのルートからの相対パスである必要があります。

include:
  - path: file/path/common.yml

ファイルを含むリポジトリを指定することで、別のリポジトリからファイルを取り込むことができます。 repository プロパティを設定する場合は、次のいずれかも設定する必要があります。

  • branch: YAML ファイルを含むブランチ。

  • commit: YAML ファイルを含める特定のコミット ハッシュ。

  • tag: YAML ファイルを指す Git タグ。

リポジトリは、プロジェクトのプライマリリポジトリが属するのと同じGitアカウントまたは組織に属している必要があります。 BitriseプロジェクトのリポジトリURL 例えば、リポジトリのURLが [email protected]:MyOrg/main_repo.git、GitHub 上の MyOrg に属するリポジトリのみを参照できます。

他のリポジトリへのアクセス

Bitriseのニーズ read 設定 YAML ファイルがホストされているすべてのリポジトリへのアクセス。Bitrise がリポジトリにアクセスできるようにするには、次の 2 つの方法があります。

リポジトリの名前を参照するだけで済みます。たとえば、 [email protected]:MyOrg/別のリポジトリ.git 価値を持つ another_repo

include:
  - path: shared/common.yml
    branch: test_branch
    repository: another_repo

include 形式

表1 インクルード形式

パラメータ

必須?

説明

デフォルト

path

必須

含める YAML ファイルの場所。パスは次のいずれかの相対パスです。

  • CI 環境におけるリポジトリのルート。

  • ローカル環境の現在のディレクトリ。

該当なし

branch

オプション

YAML ファイルを含めるブランチ。

Bitrise プロジェクトのデフォルト ブランチ。

tag

オプション

YAMLファイルを含めるタグ。 branch そして tag 両方指定されている場合は、タグが優先されます。

デフォルトでは空のままです。

commit

オプション

YAML ファイルを含める特定のコミット ハッシュ。

もし branchtag、 そして commit すべて指定されている場合は、コミットが優先されます。

Bitrise CI 環境: デフォルトでは空のままです。

ローカル環境: チェックアウトされたコミット参照。

repository

オプション

YAML ファイルをプルするリポジトリ。デフォルト以外のリポジトリのファイルを使用する場合は、これを指定する必要があります。

Bitrise CI 環境: Bitrise プロジェクトのリポジトリ URL。

ローカル環境: チェックアウトされたローカル Git リポジトリの URL。


構成モジュールの定義

設定モジュールは完全なYAML設定ファイルです。つまり、有効なモジュールのすべての設定要素が bitrise.yml ファイルが利用可能です。 format_version、アプリレベルの環境変数、デフォルトのスタックとマシンタイプ、そしてもちろん構成モジュール内のパイプライン、ステージ、ワークフロー。

例えば、最低限の bitrise.yml 単に別のモジュールを指すファイル:

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

そしてこの場合、 config_module.yml ビルドの全体的な構成が含まれています:

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: android
app:
  envs:
  - MY_NAME: My Name
workflows:
  test:
    steps:
    - script:
        inputs:
        - content: echo "Hello ${MY_NAME}!"

構成モジュールには、ルート レベルで定義された任意の構成エンティティを含めることができます。たとえば、単一のワークフローのみ、またはアプリ レベルの環境変数のみを定義する構成モジュールは完全に有効です。

bitrise.yml ファイル:

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
include:
  - path: path/to/config_module.yml

config_module.yml ファイル:

app:
  envs:
  - USER_NAME: UserName
workflows:
  test:
    steps:
    - script:
        inputs:
        - content: echo "Hello ${USERNAME}!"

ただし、ルート レベル以外のエンティティは、別のモジュール ファイル内で単独で存在することもできません。たとえば、次のようにステップ入力を含めることはできません。

含まれるモジュールのネスト

あなたは include 含まれる構成ファイル内のプロパティ:

ルートレベル bitrise.yml ファイル:

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
include:
  - path: path/to/config_module.yml

config_module.yml ファイル:

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

another_module.yml ファイル:

workflows:
  ui_test:
    steps:
    - pull-intermediate-files@1:
        inputs:
        - artifact_sources: build_tests.build_for_ui_testing

この設定により、 ui_test ワークフロー。

ネストには次の制限があります。

  • ルート レベルのファイルを含む深さ 5。

  • ファイルあたり最大 10 個のインクルード。

  • ルート レベルのファイルを含め、合計で最大 20 個の構成ファイル。

含まれるモジュールのマージルール

Bitriseがビルドを実行すると、設定モジュールが1つにマージされます。 bitrise.yml ファイル:

  • 含まれているモジュールは、ルートで定義された順序で読み込まれ、構成にマージされます。 bitrise.yml ファイル。

  • インクルードされたモジュールでも include が使用されている場合、ネストされたモジュールが最初に再帰的にマージされます。

  • includeで追加されたすべての設定ファイルがマージされた後、結果の設定は bitrise.yml ルート レベルのファイル。これにより、ルート レベルの構成値を上書きできます。

bitrise.io に戻る

複数のYAMLファイルを含むモジュール構成があり、 設定をbitrise.ioに保存するように切り替えます同じマージルールを使用して、すべてのファイルを1つのファイルにマージします。 bitrise.yml ファイル。

設定をマージする際に、重複が発生し、含まれている設定値が上書きされる可能性があります。YAML モジュールをマージする場合、最後に読み込まれたファイルが既存のマージされた設定よりも優先されます。ルールは次のとおりです。

  • 単純な型の項目 (整数やブール値など): 最後に読み取ったファイルの値が使用されます。

  • オブジェクト タイプの項目 (パイプライン、ステージ、ワークフローなど)

    • プロパティが既存のマージされた構成にのみ存在する場合、その値は保持されます。

    • 両方にプロパティが存在し、その値がハッシュ マップである場合、値はマージされます。

    • それ以外の場合は、最後に読み取られたファイルの値が使用されます。

  • 配列型の項目(例えば、環境変数のリストや トリガーマップアイテム): コレクションが最近読み取られたファイルと既存のマージされた構成の両方に存在する場合、マージされた値は値の順序付けられた配列であり、マージされた構成のすべての値の後に最近読み取られたファイルの値が続きます。

ワークフローエディタでマージされた設定ファイルを確認できます。 ビットライズ 左側のナビゲーション メニューからクリックして表示します。

例1 マージルール

私たちには根源がある bitrise.yml ファイルには config_module.yml ファイル。

bitrise.yml:

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: android

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

app:
  envs:
  - USER_ID: UserId
  - PASSWORD: SecurePassphrase

config_module.yml:

format_version: 10

app:
  envs:
  - USERNAME: UserName

workflows:
  test:
    steps:
    - script:
        inputs:
        - content: echo "Hello ${USERNAME}!"

合併中、 config_module.yml 構成にマージされます。その後、ルートレベル bitrise.yml 読み込まれ、マージされます。最終的な構成は次のようになります。

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: android

app:
  envs:
  - USER_ID: UserId
  - PASSWORD: SecurePassphrase
  - USERNAME: UserName

workflows:
  test:
    steps:
    - script:
        inputs:
        - content: echo "Hello ${USERNAME}!"
  • ルートレベル format_version プロパティは両方のファイルに存在します。ルートレベル bitrise.yml ファイルは全体の構成に最後にマージされるため、 format_version が使用されます。

  • apps プロパティは両方のファイルに存在するため、すべてのキーと値のペアが全体の構成に追加されます。

  • test ワークフローは、 config_module.yml 全体の構成に追加され、 bitrise.yml それを上書きしません。