M1スタック

概要

Bitriseは、すべてのクレジットベースのアカウントにAppleシリコンM1スタックを提供しています。 M1スタックで最新バージョンのステップを使用することをお勧めします。

Appleは2020年にAppleシリコンM1チップを発表しました。これはハードウェアアーキテクチャの根本的な変化を表しており、将来的にはすべてのiOSおよびmacOS開発がAppleシリコンを搭載したMacで行われることを意味します。そのため、BitriseはCI/CDの目的で仮想化されたM1環境を提供しています。

クレジットベースのアカウントのみ

M1スタックは利用できません 従来の同時実行ベースのアカウント

ビルド用のM1ベースのスタックの選択

他のスタックと同様に、M1ベースのスタックを選択するには2つのオプションがあります。

  • ワークフローエディタで選択します。

  • メタプロパティとして追加する bitrise.ymlファイル。

ワークフローエディタでのM1スタックの設定

  1. でアプリを開きます ビットライズ

  2. に移動します ワークフロー タブ。

  3. 関連するスタックセレクタメニューを見つけます。

    • すべてのワークフローのデフォルトスタックを設定する場合は、 デフォルトのスタック セクション。

    • ワークフロー固有のスタックを設定する場合は、 ワークフロー固有のスタック セクションを選択し、ワークフローを選択します。

  4. ドロップダウンメニューで、Xcodeバージョン13以降のXcodeスタックを選択します。

  5. の中に デフォルトスタックのマシンタイプ セクションで、M1マシンを選択します。

    infrastructure-m1-stack-machine-type-selector.png
  6. クリック 保存 右上隅にあります。

bitrise.ymlファイルにM1スタックを設定する

M1スタックをアプリのデフォルトスタックとして設定する方法について説明します。

  1. アプリを開きます bitrise.yml ファイル。

  2. 追加する meta スタックIDとマシンタイプを指定するエントリ。

    スタックIDはで見つけることができます システムレポートページ:ファイル名なし .log 拡張子はスタックIDです。 M1ベースのスタックを使用するには、Xcodeバージョン13以降のスタックの1つを選択する必要があります。マシンIDは g2-m1.8core

    デフォルトのスタックまたはワークフロー固有のスタックを設定できます。

    • デフォルトのスタックの場合、 meta 構造の最上位にあるプロパティ。たとえば、と同じレベルである必要があります format_version。ファイルの最後に配置することをお勧めします。

      meta:  
        bitrise.io:       
          stack: osx-xcode-13.4.x    
          machine_type_id: g2-m1.8core
      
    • ワークフロー固有のスタックを設定する場合は、ワークフロー自体の下にメタエントリを追加する必要があります。

      workflows:
        deploy:  
          meta:      
            bitrise.io:       
              stack: osx-xcode-13.4.x
              machine_type_id: g2-m1.8core

      この例では、ワークフロー固有のスタックを設定しています deploy ワークフロー。

IntelベースのスタックからM1への移行

開発環境をIntelベースのアーキテクチャからAppleシリコンに切り替えることは大きな変更であり、CI/CDにも影響します。 Bitriseでは、移行が可能な限りシームレスになるように努めました。ステップを更新し、最も重要なツールのM1互換バージョンをM1スタックにインストールしました。

つまり、ほとんどの場合、公式のBitriseステップを使用すると、ビルドは通常どおりに機能するはずです。それでも、すべてをローカルで、自分のM1マシンでテストすることを強くお勧めします。あなたは使用することができます Bitrise CLI そうするために。

BitriseStepバージョン

M1スタックのワークフローでは常に最新バージョンのビットライズステップを使用してください。これらは、Intelベースのスタックとも下位互換性があるように設計されています。

また、いくつかの制限があり、IntelベースのスタックからM1への移行に関して注意すべきいくつかの変更があります。最も重要なものを見ていきます。

Rosettaを使用する

Rosettaはエミュレーター/翻訳者です IntelとAppleのシリコンプロセッサ間の互換性を橋渡しするためにAppleによって設計されました。 Intelをターゲットとする実行可能ファイルを変換して、M1を搭載したマシンで実行できるようにします。

Rosettaがスタックにインストールされ、有効になっています。使用するには、 arch -x86_64 スクリプトで実行する各コマンドの前にプレフィックスを付けます。これは、x86_64命令を使用するようにシステムに指示します。

ロゼッタの制限

ロゼッタは翻訳できません:

  • カーネル拡張。

  • x86_64コンピュータープラットフォームを仮想化する仮想マシンアプリ。

XcodeおよびMacOSのバージョン要件

最も重要な要件は、Xcode13.0以降を使用する必要があることです。とにかくXcode13.0以降に移行することを強くお勧めします。 Appleは、AppStoreに送信されたアプリを受け付けなくなりました 古いバージョンのXcodeでビルドされた場合。

オペレーティングシステムに関しては、M1にはMacOSMontereyが必要です。 BigSurはAppleシリコンと互換性がありません。そのため、M1スタックはモントレーで実行されます。

AndroidSDKのバージョン要件

すべてのXcodeスタックには、クロスプラットフォームアプリのサポートの一部としてAndroidSDKも含まれています。

Googleは以前のバージョンにM1互換性を導入していないため、M1スタックにはAndroid32がインストールされています。

Homebrewのデフォルトパスへの変更

HomebrewはmacOSで最も人気のあるパッケージマネージャーであり、もちろんIntelベースとM1スタックの両方のBitriseで利用できます。

重要な違いが1つあります。パッケージのデフォルトパスが変更されました。

  • IntelベースのMacでは、パッケージのデフォルトパスは /usr/local/

  • M1ベースのMacでは、パッケージのデフォルトパスは次のとおりです。 /usr/local/bin//usr/local/share/、 と /usr/local/lib/

これは、ビルドでハードコードされたパスを使用してHomebrewパッケージにアクセスする場合にのみ重要です。その場合、パスをM1バージョンに変更する必要があります。

キャッシング

Bitriseでのキャッシュ ブランチに基づいて機能します。リポジトリの別のブランチで同じワークフローを実行すると、別のキャッシュアーカイブが作成されます。

The キャッシュ:プル ステップは、ダウンロード可能なキャッシュが現在実行中のビルドと同じスタックとCPUアーキテクチャで生成されたことを確認します。たとえば、Intelベースのスタックでビルドを実行しようとしていて、ステップがM1ベースのスタックで生成されたキャッシュアーカイブのみを検出した場合、キャッシュはダウンロードされません。これは、他のCPUアーキテクチャで生成されたキャッシュの使用に起因する安定性の問題を回避するためです。

これは、実際には、特定のブランチにアクティブなキャッシュが1つしかないことを意味します。これは、M1ベースまたはIntelベースのキャッシュのいずれかですが、両方ではありません。あなたが実行する場合 キャッシュ:プッシュ 異なるアーキテクチャのキャッシュアーカイブがあるワークフローをステップすると、そのステップはそのキャッシュアーカイブを上書きします。

キャッシングステップのバージョン要件

CPUアーキテクチャに基づいてキャッシュアーカイブを区別するロジックは、古いバージョンのキャッシュでは機能しません。手順:

  • The キャッシュ:プル ステップはバージョン2.6.0以降である必要があります。古いバージョンでは、CPUアーキテクチャに関係なく、見つかったキャッシュアーカイブがダウンロードされます。

  • The キャッシュ:プッシュ ステップはバージョン2.7.0以降である必要があります。古いバージョンでは、CPUアーキテクチャに関連するメタデータは追加されません。

その他の既知の問題と制限

M1には、他にもいくつかの制限と既知の問題があります。私たちは、ほとんどのユースケースで機能するソリューションがあることを確認するために懸命に取り組んでいます。

Androidエミュレーションは利用できません

M1スタックは、ビルドでのAndroidエミュレーターの使用をサポートしていません。これは、Bitriseが仮想マシン上でビルドを実行し、Appleシリコンアーキテクチャがネストされた仮想化を許可していないためです。

ただし、Firebase Test Labを使用して、BitriseでAndroidデバイスのテストを実行することはできます。 Androidのデバイステスト

ぶら下がっているビルドの問題

Appleのハイパーバイザーフレームワークには、私たちのような仮想化環境で問題を引き起こす可能性のあるバグがあります。この問題は、シミュレーターが起動されるたびに発生する可能性があります。たとえば、iOSステップのXcodeテストでは、iOSシミュレーターを使用してテストを実行します。シミュレーターが起動すると、ビルドが無期限にハングする可能性があります。

この問題の詳細については、チェックアウトしてください このディスカッション投稿。この問題はAppleに報告されています。

回避策は簡単です。ビルドの開始時にXcodeシミュレーターを起動し、ハングするかどうかを確認し、ハングする場合はワークフローを再起動して、ハングの問題が時間とクレジットを浪費しないようにします。

  1. 追加します Xcodeシミュレータを起動します 最初のステップワークフローとしてステップします。

    リポジトリのクローンを作成する前であっても、何よりも先にシミュレータを起動することが重要です。問題が発生しない場合、シミュレーターの起動には数秒しかかからず、ワークフローの後半でそれを使用してテストを実行できます。

  2. ステップに90秒のブートタイムアウトを追加します。ワークフローエディタまたは bitrise.yml ファイル:

    宛先デバイス

    シミュレータの宛先も必ず設定してください。 デバイス宛先指定子 ステップの入力。の中に bitrise.yml ファイルの場合、入力の名前は destination

    あなたは見つけることができます Xcodeで利用可能な宛先デバイス

    • ワークフローエディタのグラフィカルUIで: シミュレータの起動タイムアウト(秒単位) 入力して90に設定します。

    • の中に bitrise.yml、を設定する必要があります wait_for_boot_timeout 90への入力:

      - xcode-start-simulator:
          inputs:
          - destination: platform=iOS Simulator,name=iPhone 8,OS=latest
          - wait_for_boot_timeout: 90
  3. 追加します Bitriseワークフローをトリガーする 直後にワークフローに進みます Xcodeシミュレータを起動します ステップ。

    このステップを使用して、前のステップがハングしたかどうかを検出し、ハングした場合はビルドを再開します。

  4. 前のステップが失敗した場合でも実行するようにステップを設定します。ワークフローエディタまたは bitrise.yml ファイル

    • ワークフローエディタのグラフィカルUIで: 前のステップが失敗した場合に実行 トグルしてオンにします。

    • の中に bitrise.yml ファイル:設定 is_always_run に属性 true

      - trigger-bitrise-workflow:
          is_always_run: true
  5. をセットする run_if 属性:ステップは、 Xcodeシミュレータを起動します で終わった hanged 状態。

    The Xcodeシミュレータを起動します ステップは、 環境変数 シミュレータのステータスを保存します。これは、ビルドがハングしたかどうかを検出するために使用します。

    YAMLモードのみ!

    これは、 bitrise.yml アプリのファイル。

    - trigger-bitrise-workflow:
        is_always_run: true
        run_if: '{{enveq "BITRISE_SIMULATOR_STATUS" "hanged"}}'
  6. APIトークンとワークフローIDを構成します。

    • トリガーAPIトークンを作成する:あなたはそれを見つけることができます コード Bitriseのアプリのページのタブ。

    • ワークフローID:トリガーするワークフローの名前。この場合、同じワークフローである必要があります。

    の中に bitrise.yml ファイルの場合、ステップは次のようになります。

    - trigger-bitrise-workflow:
        is_always_run: true
        run_if: '{{enveq "BITRISE_SIMULATOR_STATUS" "hanged"}}'
        inputs:
        - api_token: $TRIGGER_TOKEN
        - workflow_id: my-workflow-name
例1 完全なYAMLの例
- xcode-start-simulator:
    inputs:
    - destination: platform=iOS Simulator,name=iPhone 8,OS=latest
    - wait_for_boot_timeout: 90
- trigger-bitrise-workflow:
    is_always_run: true
    run_if: '{{enveq "BITRISE_SIMULATOR_STATUS" "hanged"}}'
    inputs:
    - api_token: $TRIGGER_TOKEN
    - workflow_id: my-workflow-name

それでおしまい。ビルドがシミュレーターの段階でハングした場合、90秒以内に自動的に再起動するため、問題が膨大な時間を浪費することはありません。