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
-
でアプリを開きます ビットライズ。
-
クリック
メインページのボタン。 -
[ワークフローとパイプライン] ページでは、次のことができます。
-
クリック ビットライズ.yml ワークフローエディターのタブ。
にアクセスするためのボタン -
クリック
ワークフロー名の横にある ボタンをクリックして、ワークフロー エディターでワークフローを開きます。
-
-
関連するスタックセレクタメニューを見つけます。
-
すべてのワークフローのデフォルトスタックを設定する場合は、 デフォルトのスタック セクション。
-
ワークフロー固有のスタックを設定する場合は、 ワークフロー固有のスタック セクションを選択し、ワークフローを選択します。
-
-
ドロップダウンメニューで、Xcodeバージョン13以降のXcodeスタックを選択します。
-
の中に デフォルトスタックのマシンタイプ セクションで、M1マシンを選択します。
-
クリック
右上隅にあります。
-
アプリを開きます
bitrise.yml
ファイル。 -
を追加
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 マシンに移行する前に、移行フェーズをできるだけスムーズにするために、内部的に次の手順に従うことをお勧めします。
-
(オプション) レビュー Appleの公式ドキュメント。
-
Xcode バージョン (Xcode 13.0 以降) が Apple シリコン チップをサポートしていることを確認してください。
-
Homebrew、Ruby、および RubyGems を最新バージョンに更新します。
-
シミュレーターとローカルの物理デバイスを使用してアプリをテストします。
-
インストゥルメントまたは Xcode デバッグ ツールを使用して、アプリのクラッシュ、メモリ リーク、その他の問題を監視します。
-
互換性とパフォーマンスの問題を確認してください。
これらの手順を実行した後、Bitrise でのアプリの移行に安全に進むことができます。
M1 スタック上で最新の成功したビルドを再構築する
Bitrise 上のアプリがまだ Intel ベースのスタックを使用している場合は、次のコマンドを使用して、成功したビルドの 1 つを M1 マシンで再実行できます。
ボタン。![]() |
Bitrise では、移行が可能な限りシームレスになるよう努めてきました。ステップを更新し、最も重要なツールの M1 互換バージョンを M1 スタックにインストールしました。
これは、公式の Bitrise ステップを使用すれば、ほとんどの場合、ビルドはこれまでと同様に動作するはずであることを意味します。それでも、すべてをローカルの M1 マシンでテストすることを強くお勧めします。使用できます ビットライズ CLI そうするために。
BitriseStepバージョン
M1スタックのワークフローでは常に最新バージョンのビットライズステップを使用してください。これらは、Intelベースのスタックとも下位互換性があるように設計されています。
また、いくつかの制限があり、IntelベースのスタックからM1への移行に関して注意すべきいくつかの変更があります。最も重要なものを見ていきます。
移行パス
Apple シリコン環境への主な移行パスは 2 つあります。
-
Apple シリコン開発マシンでプロジェクトをテストできます。ビルドしてテストが正常に実行されれば、M1 (Apple シリコン) スタックでも動作します。
-
以下で iOS シミュレーターと Xcode テストを実行できます。 ロゼッタ プロジェクトで、利用可能な更新バージョンがないレガシー フレームワークを使用している場合 (つまり、
iOS Simulator arm64
アーキテクチャ スライス)。これには、実行に比べてオーバーヘッドがないビルド自体は含まれませんxcodebuild
.詳細については、チェックしてください Rosetta での iOS シミュレーターとテストの実行.
完全な Rosetta エミュレーション
Rosetta を使用するための代替オプションがあります。次を含むすべての CI ツールを実行できます。 xcodebuild
Rosetta 2 エミュレートされたスタック: Rosetta エミュレート スタックの使用.
Rosetta での iOS シミュレーターとテストの実行
Rosetta の下で iOS シミュレーターを起動してテストを実行するのは簡単です。
-
追加 iOS の Xcode テスト ステップまたはカスタム 脚本 Xcode テストを実行する手順。
-
追加
EXCLUDED_ARCHS=arm64
オプション xcodebuild:-
の中に iOS の Xcode テスト ステップ、に追加します xcodebuild コマンドの追加オプション に入力 xcodebuild 構成 入力グループ。
-
で 脚本 ステップ、最後に追加 xcodebuild 指図:
xcodebuild -workspace Sample.xcworkspace -scheme Sample test -destination 'platform=iOS Simulator,name=iPhone 11' EXCLUDED_ARCHS=arm64
-
-
ビルドを実行します。 Xcode は、Rosetta の下で iOS シミュレータを自動的に起動します。
Xcode でのオプションの設定
Xcode でオプションを設定することもできますが、必ずすべてのテスト ターゲットに適用する必要があります。詳細については、 関連する Apple テクニカル ノート.
Rosetta エミュレート スタックの使用
Rosettaはエミュレーター/翻訳者です IntelとAppleのシリコンプロセッサ間の互換性を橋渡しするためにAppleによって設計されました。 Intelをターゲットとする実行可能ファイルを変換して、M1を搭載したマシンで実行できるようにします。
Rosetta がインストールされ、特定のスタックで有効になっている。最も簡単な方法は、Rosetta 2 エミュレートされた Xcode スタックでビルドを実行することです。この方法では、以下を含むすべての CI ツール xcodebuild
、Rosetta の下で実行されます。
Ruby とノードのインストール
この方法を使用すると、Ruby とノードのインストールの両方で問題が発生する可能性があります。
-
でアプリを開きます ビットライズ。
-
クリック
メインページのボタン。 -
[ワークフローとパイプライン] ページでは、次のことができます。
-
クリック ビットライズ.yml ワークフローエディターのタブ。
にアクセスするためのボタン -
クリック
ワークフロー名の横にある ボタンをクリックして、ワークフロー エディターでワークフローを開きます。
-
-
に行く スタックとマシン タブ。
-
スタック セレクターのドロップダウン メニューを開きます。 デフォルト スタック または ワークフロー固有のスタック セクション。
-
Rosetta 2 エミュレートされた Xcode スタックを選択します。
Xcode でのビルド設定の構成
アプリが M1 マシンと互換性があることを確認するには、 ビルド設定 Xcode で:
-
Xcode でプロジェクトを開き、プロジェクト設定に移動します。ターゲットを選択し、
。 -
Apple シリコン上で macOS、iOS、watchOS、tvOS アプリの構築をサポートするには、アプリのアーキテクチャ ビルド設定を更新します。
-
下 アーキテクチャ セクション、セット アクティブなアーキテクチャのみを構築する に
Yes
ために デバッグ と リリース 構築します。これにより、コンパイラは 1 つのアーキテクチャのみに対してバイナリを生成するようになります。アーキテクチャ構築エラー
チェックアウト この記事 アーキテクチャのビルド エラーが発生した場合に考えられる解決策については、こちらを参照してください。
依存関係の更新
アプリが依存するすべてのサードパーティのライブラリ、フレームワーク、およびその他の依存関係が更新され、M1 の ARM アーキテクチャと互換性があることを確認することが重要です。
これには、特定の Carthage、SPM、CocoaPods の依存関係の更新または置換が必要になる場合があります。
依存関係を更新するには:
カルタゴ
ココアポッド
SPM
-
を含むプロジェクト ディレクトリに移動します。
Cartfile
。 -
を実行します。
carthage update --use-xcframeworks
すべての依存関係を更新するコマンドCartfile
互換性のある最新バージョンに更新します。
-
を含むプロジェクト ディレクトリに移動します。
Podfile
。 -
を実行します。
pod update
すべての依存関係を更新するコマンドPodfile
互換性のある最新バージョンに更新します。
-
Xcode で、「」を選択します。
" > " " > " 」メニューから。
特定の依存関係を置き換えるには:
カルタゴ
ココアポッド
-
を開きます。
Cartfile
。 -
必要なバージョンまたはブランチを指定して、古い依存関係を含む行を新しい依存関係に置き換えます。
-
ファイルを保存してエディタを閉じます。
-
コマンドを実行します
carthage update
ターミナルから新しい依存関係を取得し、フレームワークを構築します。
-
を開きます。
Podfile
。 -
次の構文を使用して目的のバージョンまたはブランチを指定して、古い依存関係を含む行を新しい依存関係に置き換えます。
pod 'NewDependency', '~> version'
。 -
ファイルを保存してエディタを閉じます。
-
コマンドを実行します
pod update NewDependency
ターミナルから をクリックして、新しい依存関係をインストールし、プロジェクトのワークスペースを更新します。
Carthage、SPM、CocoaPods の依存関係を更新した後、プロジェクトで使用されているカスタム ビルド スクリプトまたはツールを確認します。これらには、ARM アーキテクチャと互換性のあるバージョンに更新または置き換える必要があるコード アナライザーやその他の開発ツールが含まれる場合があります。
Web サービス、API、プラグイン、および拡張機能
アプリが Web サービスと API に依存している場合は、これらのサービスが Apple シリコン上で実行されるアプリと互換性があり、十分にテストされていることを確認してください。
アプリがプラグインまたは拡張機能をサポートしている場合、これらのコンポーネントを更新または置換するか、サードパーティ開発者がプラグインまたは拡張機能を更新するためのガイドラインを提供する必要がある場合があります。
iOS シミュレーター ビルドの ARM64 アーキテクチャを除く
アプリは、Apple Silicon と互換性のあるバージョンを持たない依存関係に依存している可能性があります。その場合、次のようなビルド エラーが発生します。
building for iOS Simulator, but linking in object file built for iOS,for architecture arm64
note: 'Example.xcframework' is missing architecture(s) required by this target(arm64), but may still be link-compatible. (in target 'ExampleApp' from project'ExampleApp')
その場合、プロジェクトのビルド時に ARM64 アーキテクチャを除外するようにビルド設定を構成できます。
追い越し車線
SPM
ココアポッド
カルタゴ
fastlane を使用してアプリを構築しており、ARM64 アーキテクチャを除外する必要がある場合:
-
ビルド設定に次の行を追加します。
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = 'arm64'
例1 ARM64 を除外した Fastfiledesc 'Run Tests' lane :run_tests do |options| APP = "#{APP}" unless options[:framework begin run_tests( scheme: APP, xcargs: "EXCLUDED_ARCHS='[sdk=iphonesimulator*] arm64'" ) rescue StandardError end end
Swift プロジェクト マネージャーの場合、ARM64 アーキテクチャを除外するための特定の設定はありません。関連する設定を使用して除外を構成する必要があります xcodebuild 国旗:
-
Xcode では、Xcode ビルド設定のすべてのターゲットから ARM64 アーキテクチャを除外できます。詳細については、を参照してください。 Appleの公式ドキュメント。
-
Bitrise では、関連するフラグを xcodebuild すべての公式 Xcode ステップのコマンド。を見つける xcodebuild コマンドの追加オプション 入力して追加する
EXCLUDED_ARCHS=arm64
。サポートされているステップには次のものが含まれます。
CocoaPods の場合は、Pod ターゲットを構成する必要があります。実際の手順は、Pod を所有しているか、外部の Pod を使用しているかによって多少異なります。
-
独自のポッドの場合は、以下を
.podspec
ファイル:s.pod_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' } s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }
-
制御できない外部ポッドの場合、
.podspec
ファイルに次のスニペットを貼り付けますPodfile
:post_install do |installer| installer.pods_project.build_configurations.each do |config| config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64" end end
ビルド設定の上書き
スニペットにより、実行するたびに必要なビルド設定が確実に設定されます。 pod install。ポッド ターゲットのビルド設定で ARM64 を手動で除外できますが、このスニペットはありません。 pod install 実行するたびにこれらの設定が上書きされます。
-
次のスクリプトを実行します。 脚本 カルタゴのコマンドを呼び出す前のステップ
xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX) trap 'rm -f "$xcconfig"' INT TERM HUP EXIT CURRENT_XCODE_VERSION="$(xcodebuild -version | grep "Xcode" | cut -d' ' -f2 | cut -d'.' -f1)00" CURRENT_XCODE_BUILD=$(xcodebuild -version | grep "Build version" | cut -d' ' -f3) echo'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_${CURRENT_XCODE_VERSION}__BUILD_${CURRENT_XCODE_BUILD} = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig echo'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_'${CURRENT_XCODE_VERSION}' = $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_$(XCODE_VERSION_MAJOR)__BUILD_$(XCODE_PRODUCT_BUILD_VERSION))' >> $xcconfig echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig export XCODE_XCCONFIG_FILE="$xcconfig" envman add --key XCODE_XCCONFIG_FILE --value "$xcconfig"
XcodeおよびMacOSのバージョン要件
最も重要な要件は、Xcode13.0以降を使用する必要があることです。とにかくXcode13.0以降に移行することを強くお勧めします。 Appleは、AppStoreに送信されたアプリを受け付けなくなりました 古いバージョンのXcodeでビルドされた場合。
オペレーティング システムに関しては、M1 には macOS Monterey 以降のバージョンが必要です。 Big Sur は Apple シリコンと互換性がありません。
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バージョンに変更する必要があります。
その他の既知の問題と制限
M1には、他にもいくつかの制限と既知の問題があります。私たちは、ほとんどのユースケースで機能するソリューションがあることを確認するために懸命に取り組んでいます。
Androidエミュレーションは利用できません
M1スタックは、ビルドでのAndroidエミュレーターの使用をサポートしていません。これは、Bitriseが仮想マシン上でビルドを実行し、Appleシリコンアーキテクチャがネストされた仮想化を許可していないためです。
ただし、Firebase Test Labを使用して、BitriseでAndroidデバイスのテストを実行することはできます。 Androidのデバイステスト。
ぶら下がっているビルドの問題
Appleのハイパーバイザーフレームワークには、私たちのような仮想化環境で問題を引き起こす可能性のあるバグがあります。この問題は、シミュレーターが起動されるたびに発生する可能性があります。たとえば、iOSステップのXcodeテストでは、iOSシミュレーターを使用してテストを実行します。シミュレーターが起動すると、ビルドが無期限にハングする可能性があります。
この問題は Apple に報告されており、macOS Ventura で公開される修正プログラムがテストされています。それまでは、回避策を使用することをお勧めします。
出力なしでぶら下がっているステップの検出と中止
以外のハングステップが発生している場合 Xcode シミュレーターを起動する ステップ、私たちのガイドをチェックしてください 出力なしでぶら下がっているステップの検出と中止.
回避策は簡単です。ビルドの開始時に Xcode シミュレーターを起動し、ハングするかどうかを確認し、ハングする場合はワークフローを再起動して、ハングの問題で時間とクレジットが無駄にならないようにします。
-
追加 Xcode シミュレーターを起動する 最初のステップ ワークフローとしてのステップ。
リポジトリを複製する前であっても、何よりもまずシミュレーターを起動することが重要です。問題が発生しない場合は、シミュレーターの起動に数秒しかかからず、後でワークフローで使用してテストを実行できます。
-
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
-
-
追加 Bitrise ワークフローのトリガー の直後にワークフローに進みます Xcode シミュレーターを起動する ステップ。
このステップを使用して、前のステップがハングしたかどうかを検出し、ハングした場合はビルドを再開します。
-
前のステップが失敗した場合でもステップを実行するように設定します。ワークフロー エディターまたは
bitrise.yml
ファイル-
ワークフロー エディターのグラフィカル UI で: 前のステップが失敗した場合に実行 トグルしてオンにします。
-
の中に
bitrise.yml
ファイル: 設定is_always_run
属性true
.- trigger-bitrise-workflow: is_always_run: true
-
-
をセットする
run_if
属性: ステップは、 Xcode シミュレーターを起動する で終わったhanged
状態。の Xcode シミュレーターを起動する ステップは 環境変数 シミュレーターの状態を保存します。これは、ビルドがハングしたかどうかを検出するために使用するものです。
YAML モードのみ!
これは、
bitrise.yml
あなたのアプリのファイル。- trigger-bitrise-workflow: is_always_run: true run_if: '{{enveq "BITRISE_SIMULATOR_STATUS" "hanged"}}'
-
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
-
- 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 秒以内に自動的に再起動されるため、問題によって膨大な時間が浪費されることはありません。