This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.
Git タグで本番デプロイをトリガーする
ページを編集
EAS Workflows で Git タグから本番デプロイをトリガーする方法を学びます。
リリースブランチへプッシュする方式では、リリースのつもりがなかったコミットも含め、コミットのたびに本番ワークフローが実行されてしまいます。
この章で学べること
- 本番ワークフローのトリガーを
release/*ブランチからv*.*.*に一致する Git タグへ切り替える mainからタグをプッシュしてリリースを切り、EAS ダッシュボードでワークフローの実行を確認するv1.0.0-rc.1のようなプレリリースタグを本番から除外し、リリース候補は別のワークフローで実行する
リリースイベントとしてのタグ
EAS Workflows は、on.push に tags のリストを指定することで、タグベースのトリガーに対応しています。ワークフローは、glob パターンに一致するタグがリモートへプッシュされたときにだけ実行されます。Git のタグは、あとから更新できるブランチとは違い、特定のコミットとバージョンに紐づいた一度きりのイベントです。そのため、タグはリリースの目印として適しています。
タグベースのリリースワークフローは、次のようなチームに向いています。
- Git 上のバージョン番号と、アプリのユーザーに届けるバージョンを一致させたい
- 長期間維持するリリースブランチを持たず、
mainから直接リリースしたい - すべてのリリースコミットをバージョンごとに追跡できる、明確な記録を残したい
production.yml をタグトリガーに切り替える
前の章の .eas/workflows/production.yml ワークフローを開き、on.push.branches トリガーを on.push.tags に置き換えます。ワークフローの中身はそれ以外まったく同じです。
1
トリガーを変更する
branches トリガーを tags トリガーに置き換えます。この tags の glob は、v1.0.0、v2.3.7、v10.0.0-beta.1 といったタグに一致します。
name: Deploy to production on: push: tags: ['v*.*.*'] jobs: fingerprint: name: Fingerprint type: fingerprint environment: production get_android_build: name: Check for existing Android build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }} profile: production get_ios_build: name: Check for existing iOS build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }} profile: production build_android: name: Build Android needs: [get_android_build] if: ${{ !needs.get_android_build.outputs.build_id }} type: build params: platform: android profile: production build_ios: name: Build iOS needs: [get_ios_build] if: ${{ !needs.get_ios_build.outputs.build_id }} type: build params: platform: ios profile: production update_android: name: Publish Android update needs: [get_android_build] if: ${{ needs.get_android_build.outputs.build_id }} type: update params: branch: production platform: android update_ios: name: Publish iOS update needs: [get_ios_build] if: ${{ needs.get_ios_build.outputs.build_id }} type: update params: branch: production platform: ios
タグでワークフローをトリガーするには、チームの進め方に合ったパターンを選ぶ必要があります。よく使われるパターンは次のとおりです。
['v*']はvで始まるすべてのタグに一致します['v*.*.*']は 3 つの数値からなる厳密なセマンティックバージョンに一致します（推奨）
他のジョブを変更する必要はありません。fingerprint、get-build、build、update の各ジョブはコミットを対象に動作するため、まったく同じように機能します。
2
3
タグを作成してワークフローをテストする
ワークフローを実行するには、production.yml に定義した glob パターンに一致するタグをプッシュする必要があります。
サンプルプロジェクトに TypeScript/JavaScript の変更を加えてコミットし、新しいタグをプッシュします。
- git add .- git commit -m "Fix welcome copy"- git tag v0.1.0- git push origin main --tagsv0.1.0 タグによってワークフローがトリガーされます。EAS ダッシュボードを開いて Workflows の下を見ると、"Deploy to production" がブランチとして refs/tags/v0.1.0 を伴って実行されているのが分かります。
タグベースのリリースとして生成されたフィンガープリントでの本番実行はこれが初めてなので、Android と iOS の両方で build ジョブが実行されます。以降のタグが TypeScript/JavaScript の変更を指している場合は、ビルドジョブがスキップされて update ジョブに直行します。
リリース候補向けのプレリリースタグ
v*.*.* の glob は v1.0.0-rc.1 のようなプレリリースタグにも一致するため、そのままではリリース候補がアプリのユーザーに届いてしまいます。リリース候補を本番から締め出すには、本番ワークフローのトリガーからそれらを除外します。
on: push: tags: ['v*.*.*', '!v*.*.*-rc.*']
本番リリースの前にリリース候補を試すには、プレリリースタグだけに一致する別のワークフロー（tags: ['v*.*.*-rc.*']）を作成し、update と submit のジョブを除いた fingerprint、get-build、build のジョブを再利用します。これで同じパイプラインが動きつつ、アプリのユーザーには何も届きません。
まとめ
第 6 章：タグベースのリリース
本番ワークフローのトリガーをリリースブランチから Git タグへ切り替え、main からバージョンタグをプッシュして変更をテストし、プレリリースタグの glob でリリース候補を締め出す方法を学びました。
次の章では、ワークフローから EAS Hosting へ web ビルドをデプロイする方法を学びます。