Skip to main content

M1スタック

概要

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

Apple は 2020 年に Apple シリコン M1 チップを発表しました。これはハードウェア アーキテクチャの根本的な変化を表しており、将来的にはすべての iOS および macOS の開発が Apple シリコンを搭載した Mac で行われることを意味します。そのため、Bitrise は CI/CD の目的で仮想化された M1 環境を提供しています。当社の Xcode スタックはデフォルトで M1 マシン上で実行されます。 Intel ベースの Xcode スタックを引き続き選択できますが、パフォーマンスが大幅に向上した M1 マシンに切り替えることをお勧めします。

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

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

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

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

Workflow Editor

bitrise.yml

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

  2. クリック ワークフロー メインページのボタン。

    opening-workflow-editor.png

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

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

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

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

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

    infrastructure-m1-stack-machine-type-selector.png

  6. クリック 保存 右上隅にあります。

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

  2. を追加 meta とのエントリー bitrise.io 2 つのプロパティを含むプロパティ: stack と machine_type_id、スタック ID とマシンタイプを指定します。

    でスタック ID を見つけます。 システム レポート ページ: を含まないファイル名 .log 拡張子はスタック ID です。 M1 ベースのスタックを使用するには、Xcode バージョン 13 以降のスタックのいずれかを選択する必要があります。

    マシンの種類は次のとおりです。 マシンタイプを構築する. M1 マシンの場合、サブスクリプション プランに応じて、次の 3 つのオプションがあります。 g2-m1.8core、 g2-m1-max.5core、 g2-m1-max.10core.

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

    • デフォルトのスタックの場合、 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 に報告されており、macOS Ventura で公開される修正プログラムがテストされています。それまでは、回避策を使用することをお勧めします。

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

以外のハングステップが発生している場合 Xcode シミュレーターを起動する ステップ、私たちのガイドをチェックしてください 出力なしでぶら下がっているステップの検出と中止.

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

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

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

  2. Step に 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 状態。

    の 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 秒以内に自動的に再起動されるため、問題によって膨大な時間が浪費されることはありません。

このセクションの内容:
bitrise.ymlbitrise.yml