This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.
EAS Workflows で開発ビルドを自動化する
ページを編集
EAS Workflows で Android と iOS の開発ビルドを自動化し、JavaScript のみの変更ではフィンガープリントを使って再ビルドをスキップする方法を学びます。
GitHub リポジトリへプッシュするたびに開発クライアントを手動で再ビルドするのは、時間がかかります。ネイティブの変更（新しいモジュール、新しいパーミッション、SDK のアップグレード）を取り込んだチームメンバーや新しいコントリビューターは、プロジェクトを動かす前に新しいビルドの完了を待つことになります。
main ブランチで開発ビルドを自動化しておけば、インストールできる最新のビルドが常に用意されている状態を保てます。eas build:dev を実行すれば、互換性のある最新のビルドをインストールできます。プロジェクトのフィンガープリントが既存のビルドと一致する場合、EAS は新しくビルドを作らずにそのビルドをダウンロードします。
この章で学べること
buildジョブタイプで Android と iOS の開発ビルドを自動化するfingerprintジョブとget-buildジョブを使い、ネイティブコードに変更がないときは再ビルドをスキップする- テストの成功をワークフローの通過条件にする、ユニットテスト用のカスタムジョブを追加する
1 件
1 件
EAS CLI は、あるプロファイルで初めてビルドをトリガーしたときに認証情報の生成を促します。ワークフローが走る前に認証情報が用意されているよう、Android と iOS の両方で開発ビルドを手動でトリガーしておきます。
- eas build --profile development --platform all開発ビルド向けの build ジョブタイプ
build ジョブタイプは、EAS Workflows の事前パッケージ済みジョブの 1 つです。ビルドプロセスの各ステップを自分で定義する代わりに、build ジョブタイプを使って Android と iOS の EAS Build を実行します。
この章では、eas.json の development ビルドプロファイルを使用します。このプロファイルは Expo アプリの開発中に使用するものです。
1
build.yml を追加する
.eas/workflows/ の中に build.yml という新しいファイルを追加します。このファイルでは、build ジョブタイプに profile と platform のパラメーターを指定して、Android と iOS の開発ビルドを作成します。
build.yml ファイルに次のコードを追加します。
name: Development builds jobs: build_android: name: Build Android type: build params: platform: android profile: development build_ios: name: Build iOS type: build params: platform: ios profile: development
build_android と build_ios の 2 つのジョブを追加しました。どちらも build タイプで、プラットフォームとビルドプロファイルのパラメーターだけが異なります。
各ジョブの params キーには次のものを指定しています。
3
EAS ダッシュボードで確認する
EAS ダッシュボードの Workflow graph タブを見ると、"Triggered manually" と表示されています。Trigger が Manual になっているときは、そのワークフローが eas workflow:run コマンドで開始されたことを意味します。
各ビルドのログはワークフローの画面内に表示されます。ビルドの ID をクリックすると、そのビルドの EAS Build ページが開きます。
EAS Workflows では、依存関係のないジョブはデフォルトで並列に実行されます。上のワークフローでは、build_androidとbuild_iosのどちらのジョブにも依存関係がないため、同時に開始されます。
次のステップに進む前に、両方のビルドが完了するのを待ちます。完了したら、Install または Open with Orbit ボタンを使うか、Artifacts からダウンロードして、デバイス/エミュレーター/シミュレーターにインストールできます。
フィンガープリントで不要なビルドをスキップする
プロジェクトの変更が TypeScript/JavaScript のみの場合、既存の開発ビルドはそのまま使えるので、新しいビルドは必要ありません。
Expo Fingerprint は、この判断を自動化します。プロジェクトのネイティブの特徴（依存関係、ネイティブプロジェクトのファイル、設定）をハッシュ化し、そのハッシュが既存のビルドと一致すればネイティブコードは変わっていないと判断して、EAS は再ビルドをスキップします。ハッシュが異なる場合はネイティブコードが変わったということなので、EAS は新しいビルドを作成します。
ネイティブの変更を検知して必要なときだけビルドするよう、build.yml をステップごとに更新していきましょう。
1
fingerprint ジョブを追加する
事前パッケージ済みの fingerprint ジョブは、プロジェクトのネイティブの特徴をハッシュ化し、プラットフォームごとにフィンガープリントのハッシュを出力します。environment フィールドは、どの環境変数の設定を使うかを EAS に伝えます。なお、environment と profile は同じ名前を持つことがありますが、指すものは異なります。profile は eas.json のビルドプロファイル（どうビルドするか）を指し、environment は EAS 上に設定された環境変数（ビルド時にどの値を注入するか）を指します。
build.yml を更新して、ビルドジョブの前に fingerprint ジョブを追加します。
name: Development builds jobs: fingerprint: name: Fingerprint type: fingerprint environment: development build_android: # ... build_ios: # ...
fingerprint ジョブは、android_fingerprint_hash と ios_fingerprint_hash という 2 つの出力を生成します。次のステップでは、これらのハッシュを使って互換性のあるビルドがすでに存在するかどうかを確認します。
2
get-build ジョブを追加する
事前パッケージ済みの get-build ジョブは、指定したフィンガープリントのハッシュとプロファイルに対応するビルドがすでに存在するかを確認します。一致するビルドがあれば build_id を出力し、なければ build_id は空になります。
ワークフローファイルの fingerprint とビルドジョブの間に、get_android_build と get_ios_build のジョブを追加しましょう。どちらも needs: [fingerprint] を使って fingerprint ジョブの完了を待ち、その出力にアクセスします。
name: Development builds jobs: fingerprint: # ... get_android_build: name: Check for existing Android build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }} profile: development get_ios_build: name: Check for existing iOS build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }} profile: development build_android: # ... build_ios: # ...
上のワークフローでは、get-build ジョブが ${{ needs.fingerprint.outputs.* }} という式の構文を使って、前のジョブからフィンガープリントのハッシュを受け取っています。
3
条件付きのビルドを追加する
if フィールドは、ジョブを実行するかどうかを制御します。${{ !needs.get_android_build.outputs.build_id }} という式は、get-build が一致するビルドを見つけられなかった場合にのみジョブを実行する という意味です。! は否定の演算子です。このフィンガープリントに対応する互換性のあるビルドがすでに存在する場合、ビルドジョブはスキップされます。
各ビルドジョブが対応する get-build ジョブに依存するよう更新し、if 条件を追加しましょう。
name: Development builds jobs: fingerprint: # ... get_android_build: # ... get_ios_build: # ... build_android: name: Build Android needs: [get_android_build] if: ${{ !needs.get_android_build.outputs.build_id }} type: build params: platform: android profile: development build_ios: name: Build iOS needs: [get_ios_build] if: ${{ !needs.get_ios_build.outputs.build_id }} type: build params: platform: ios profile: development
4
トリガーを追加してワークフローを実行する
main へのプッシュのたびに自動実行されるよう、ワークフローに on.push トリガーを追加しましょう。
name: Development builds on: push: branches: ['main'] jobs: fingerprint: name: Fingerprint type: fingerprint environment: development get_android_build: name: Check for existing Android build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }} profile: development get_ios_build: name: Check for existing iOS build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }} profile: development build_android: name: Build Android needs: [get_android_build] if: ${{ !needs.get_android_build.outputs.build_id }} type: build params: platform: android profile: development build_ios: name: Build iOS needs: [get_ios_build] if: ${{ !needs.get_ios_build.outputs.build_id }} type: build params: platform: ios profile: development
ここで、ボタンの色を変えたり画面のテキストを更新したりといった、TypeScript/JavaScript の変更を Expo プロジェクトに加えたとしましょう。変更したら、main ブランチにコミットをプッシュして、GitHub リポジトリからワークフローをトリガーできます。
- git add .- git commit -m "Update button label and tweak styling"- git push origin mainこれにより新しいワークフローがトリガーされ、数秒で完了します。EAS ダッシュボードでは、前のセクションで作成した一致するビルドがすでに存在するため、Android と iOS のビルドがどちらもスキップされています。
main ブランチから最新を取得して npx expo start を実行します。既存の開発ビルドが JS の変更を読み込みます。
ユニットテスト用のカスタムジョブ
このセクションは、プロジェクトに Jest が設定済みであることを前提としています。設定方法については Jest によるユニットテストを参照してください。
チームで作業するときは、main ブランチにプッシュされたすべての変更が、新しいビルドをトリガーする前にテストを通過してほしいものです。
自動化されていないと、チームは main にプッシュする前にローカルでテストを実行することを覚えておかなければなりません。忘れたままテストが失敗するコードをプッシュすると、次のワークフローが壊れたコードからビルドを作ってしまう可能性があります。
EAS Workflows では、既存の事前パッケージ済みジョブにカスタムジョブを組み合わせることで、このプロセスを自動化できます。このカスタムジョブは fingerprint ジョブとビルドジョブの前に実行されます。テストが失敗した場合、EAS はワークフローを停止し、ビルドは作成されません。
1
ユニットテスト用のカスタムジョブを追加する
build.yml ワークフローファイルに、ビルドが始まる前にユニットテストを実行するカスタムジョブを追加しましょう。
name: Development builds on: push: branches: ['main'] jobs: run_tests: name: Run unit tests steps: - uses: eas/checkout # Check out the repo - uses: eas/install_node_modules - run: npx jest --ci fingerprint: name: Fingerprint needs: [run_tests] type: fingerprint environment: development get_android_build: # ... get_ios_build: # ... build_android: # ... build_ios: # ...
カスタムジョブ run_tests は、次のことを行っています。
uses: eas/checkoutは、GitHub リポジトリからプロジェクトのソースファイルをチェックアウトします。カスタムジョブは新しい仮想マシン上で実行されるため、コードはデフォルトでは利用できません。プロジェクトのファイルにアクセスする前に、このステップが必要です。uses: eas/install_node_modulesは、プロジェクトで検出されたパッケージマネージャー（bun、npm、pnpm、Yarn）を使って依存関係をインストールします。Jest のように node_modules のパッケージに依存するコマンドを実行する前に必要です。run: npx jest --ciはテストスイートを実行します。runキーは、先ほどのechoコマンドと同じように、任意のシェルコマンドを実行します。--ciフラグは Jest を CI モードで実行するよう指示するもので、ファイル変更の監視を行わず、すべてのテストを実行したあとに終了します。
これで fingerprint ジョブには needs: [run_tests] が付いたので、テストが成功したあとにのみ実行されます。テストが失敗した場合、EAS はワークフローの残りをスキップします。
2
まとめ
第 2 章：開発ビルド
事前パッケージ済みジョブを使って開発ビルドを自動化し、フィンガープリントを追加して不要な再ビルドをスキップし、ビルドパイプラインの前段にカスタムジョブとしてユニットテストを組み込みました。
次の章では、Slack 通知付きのプレビュービルドと、PR プレビューアップデートを作成する方法を学びます。