React製サイトをGitHub Actionsを使ってFirebase Hostingへ自動デプロイ
2021年7月23日追記
現在はFirebaseとGithubActionsの連携がさらに強化され、GithubActions経由のデプロイがかなり便利になっています。詳しくは下記をご参照ください。
概要
ポートフォリオサイト(https://okaryo.io)をFirebase Hostingで運用していたのだが、masterブランチにマージするたびにローカルでビルドとデプロイをしていたのがめんどくさくなった。そこで、GitHub Actionsを使って自動ビルド・デプロイさせることにした。
この記事では、設定手順やその際に詰まった点をまとめる。
前提
Firebase Hostingでプロジェクトをあらかじめ作っていて、firebase-tools
のインストールやfirebase.json
の設定は済んでいるものとする。
手順
FIREBASE_TOKENの設定
Firebase Hostingへのデプロイにはfirebase-tools
を使って、firebase deploy
コマンドで実行できる。それをGitHub Actionsにやらせるので、認証用のトークンをGitHubに登録しておく必要がある。
ローカルで以下のコマンドを実行する。firebase-toolsをローカルに落としていることが前提だ。
firebase login:ci
認証を進めると、トークンが発行される。GitHubのレポジトリページから、Settings -> Secrets -> New secret
という導線順で以下のページに行き、先ほどのトークンを登録する。
デプロイ用yamlの作成
以下のyamlファイルを.github/workflow/main.yml
(ファイル名は自由)に置く。
name: Build and Deploy
on:
push:
branches:
- master
jobs:
build:
name: build
runs-on: ubuntu-latest
steps:
- name: checkout
uses: actions/checkout@master
- name: npm install
run: npm install
- name: build
run: npm run build
- name: persist to workspace
uses: actions/upload-artifact@master
with:
name: build
path: build
deploy:
name: deploy
needs: build
runs-on: ubuntu-latest
steps:
- name: checkout
uses: actions/checkout@master
- name: download workspace
uses: actions/download-artifact@master
with:
name: build
path: build
- name: install firebase-tools
run: sudo npm install -g firebase-tools
- name: deploy
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
run: firebase deploy --token $FIREBASE_TOKEN --project Firebaseのプロジェクト名
ワークフローの構文については公式のドキュメントがよくまとまっているのでそちらを参考にしてほしい。CircleCIなどに触ったことがあれば、構文の理解に困ることは少ないと思われる。
→ https://docs.github.com/ja/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions
npmスクリプトは各自のお手製のものを使用してほしい。ひとまずこれで、masterブランチへのpushやマージで自動ビルド・デプロイが走るようになったはずだ。
以下、設定する上で詰まった箇所を挙げておく。
詰まった箇所
artifactという概念
GitHub Actionsではジョブ間でのデータのやりとりをartifactsというものを使って行うらしい。 ドキュメント
Artifacts allow you to share data between jobs in a workflow and store data once that workflow has completed.
今回のyamlファイルの中では以下の箇所がそうだ。
# build job
- name: persist to workspace
uses: actions/upload-artifact@master
with:
name: build
path: build
# deploy job
- name: download workspace
uses: actions/download-artifact@master
with:
name: build
path: build
build jobからdeploy jobへ、ビルドしたファイルを送っている。(CircleCIのpersist_to_workspace
を引きずった名前にしたが、素直にupload artifact
でよかったな。。)
一つのジョブの中でビルドとデプロイをしてしまえばartifactのやりとりは必要ないが、やはりジョブは分けたい。エラーがあった際に、どちらのジョブでの問題か分かりやすくもなるし、再利用性やコードの見やすさも高まる。
firebase-toolsのインストールでpermission error
ジョブの中でfirebase-tools
をインストールしようとnpm install -g firebase-tools
を実行すると、permission errorで落ちてしまった。
こちらはsudo
をつけることで回避した。
参考にしたサイトの中でsudu
をつけたものはなかったが、これはおそらくnpm packageとしてpackage.json
の中にfirebase-tools
を入れているのではないか。個人的にはpackage.json
に入れたくなかったので、ジョブの中でsudo
することでお茶を濁した。
所感
masterブランチにマージするだけでビルドとデプロイが自動で走るようになり、かなり楽チンになった。
手間やストレスがなくなり、開発が快適で素早く行うことができるといった点で、こういったCI/CDツールはプロジェクトの始めにこそ入れておいた方が良いと感じた。
また、GitHub Actionsについては基本的な機能しか今回触っていないが、導入も簡単で基本的な機能は揃っており、何よりGitHubで完結できるという点でCI/CDツールの選択肢の一つに十分挙がりうるものだと感じた。
参考
ワークフローの構文についての公式ドキュメント
https://docs.github.com/ja/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions
yaml作成にあたり参考にしたサイト
https://github.com/marketplace/actions/github-action-for-firebase
artifactについての公式ドキュメント
https://docs.github.com/ja/free-pro-team@latest/actions/guides/storing-workflow-data-as-artifacts