GatsbyサイトをGithubActionsでdeploy
2020.01.27
GiHub Pages上に、GiHub Actionsを用いてGatsby静的サイトをデプロイする方法をまとめました。最近よく耳にするCI/CDとかいうやつの初級編ですかね。
これは何
このブログは元々Netlify上にホスティングされていたのですが、どうも読み込み速度が遅かったので他のWebホスティングサービスも試してみることにしました。
Amplify(S3)とGitHub Pages、Netlifyの三つを比較してみたところ、読み込み速度的にはAmplify > GitHub Pages > Netlifyの順に良い結果がでたのですが、Amplifyは無料枠を使い切るとビルド時間とアップロードするデータ量に対して料金が発生してしまうので、結局無料で利用できるGitHub Pagesに引っ越すことに決定。
NetlifyにはGitHubの特定のbranchを登録しておくと、そのブランチがpushされたタイミングで自動的にサイトをデプロイしてくれる機能があるのですが、GitHub Pagesで同じことをしようとすると自分で処理を書かないといけません。
幸い、GitHubでもGitHub Actionsという継続的インテグレーション/継続的デプロイ(CI/CD)を支援するサービスが提供されているので、今回はそれを利用してGitHubの特定のブランチにpushされたタイミングで自動的にWebサイトを更新する機能を実現したいと思います。
GitHub Actionsとは
GitHub Actionsは特定のブランチに対するpushやissueなどのイベントをトリガーとして、一連のタスクであるワークフローを実行できるサービスです。
特定のブランチのルートディレクトリ以下に、.github/workflows/hogehoge-actions.ymlというファイルを作成しておけばそのブランチに対するイベント発生時にyamlファイルを読み込み、記述したワークフローを実行してくれます。
トリガーとして利用でいるイベントは投稿時現在で以下の通りです。(正確な情報は公式ドキュメントを参照してください)
valid event
"check_run", "check_suite", "create", "delete", "deployment", "deployment_status", "fork", "gollum", "issue_comment", "issues", "label", "member", "milestone", "page_build", "project", "project_card", "project_column", "public", "pull_request", "pull_request_review", "pull_request_review_comment", "push", "release", "status", "watch", "repository_dispatch"
タスクには、通常のシェルコマンドの他に、アクションと呼ばれるjavascriptで記述されたモジュールやDockerを指定することもできます。
GitHubやDockerHub上には便利なActionが多数公開されているので積極的に使っていきます。
設定項目
yamlファイルで設定する項目をテーブル形式でまとめました。
今回使用した項目のみ含まれているので、詳しい説明はGitHub Actionsのワークフロー構文 - GitHub ヘルプをご参照ください。
項目 | 説明 |
---|---|
on | トリガーをpushなどのイベントネームで指定。複数可能。複数の場合はどれか1つでも当てはまると実行。 |
on.<event name>.branches | ワークフローが実行されるbranchを指定。 |
jobs | 一つ以上のjobを指定。 |
jobs.<job_id>.runs-on | jobが実行される環境を指定。 |
jobs.<job_id>.steps | 一つ以上のタスクを指定。逐次的に実行され、どこかで失敗すると処理は中断。 |
jobs.<job_id>.steps.uses | GitHubやDockerHubに公開されているアクションを指定。 |
jobs.<job_id>.steps.run | コマンドを指定。 |
jobs.<job_id>.steps.env | 環境変数を指定。 |
ワークフローをyaml形式で記述
作成したyamlファイルは以下の通りです。deploy keyやsecreatsの設定方法等は以下のサイトをご参照ください。
またyamlの記法については、以前Jsonとの比較をまとめた記事を作成したのでそちらもご参照ください。
<user-name>.github.ioというレポジトリのdeployブランチでpushイベントが発生した際に、Gatsbyサイトをビルドし、masterブランチへデプロイしています。
name: build and deploy github pages
on:
push:
branches:
- deploy
jobs:
build-gatsby-site-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v1
- run: npm install
- run: npm run build
- uses: peaceiris/actions-gh-pages@v2.4.0
env:
ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }}
PUBLISH_BRANCH: master
PUBLISH_DIR: ./public
- name: Add CNAME file
run: |
git config user.email $EMAIL
git config user.name "DaichiTakigawa"
git remote set-url origin https://DaichiTakigawa:${GITHUB_TOKEN}@github.com/DaichiTakigawa/DaichiTakigawa.github.io.git
git checkout master
git pull
echo www.takigawa-memo.com > CNAME
git add CNAME
git commit -m 'add CNAME file'
git push
env:
GITHUB_TOKEN: ${{ github.token }}
EMAIL: ${{ secrets.EMAIL }}
まとめ
カスタムドメインを設定するためのCNAMEファイルなどはgatsbyのプラグインgatsby-plugin-cname | GatsbyJSを利用すれば簡単に配置できるのですが、せっかくなのでGitHub Actionsを使ってpushしました。
拙い文章であったと存じますが、最後まで読んでいただきありがとうございました。
2020/03/09 追記
Gatsbyではstaticという名前のディレクトリをプロジェクトのルートディレクトリに作成しておくと、ビルド時にstaticディレクトリ内のファイルを全て、ビルド先のルートディレクトリ(デフォルトではpublic)に展開してくれるそうです。
ですので、CNAMEファイルをstaticディレクトリ内に置いておけば、プラグインを使わなくても、またCD時に追加の処理を書かなくても、ちゃんとデプロイ先のルートディレクトリに配置されます。
参考リンク
コメント
この記事のコメントを読み込み中です