😎
Pull RequestごとにGitHub Pagesでプレビューページを作る
やりたいこと
- GitHub Pagesを使っているプロジェクトで、Pull Requestごとにプレビューページを自動作成したい
動いている様子
- NetlifyのDeploy Preivewsのサブセット的なもの
実装方針
- GitHub ActionsでPRの作成ごとに一時的なリポジトリを作り、そのリポジトリのGitHub Pagesにプレビューページをデプロイする
- PRがcloseされたらプレビュー用のリポジトリも削除する
元ネタはMultiple Environments With GitHub Pages | by Markus Kottländer | Geek Culture | Mediumです。基本的なアイデアはそのまま頂きました。実装の詳細をいくつか変更しています。(後述します)
実装の詳細
-
https://github.com/GoCon/2021autumn/blob/main/.github/workflows/deploy_preview.yml
- PRのopen, reopen, 対応するブランチにpushしたときに起動するワークフロー
-
https://github.com/GoCon/2021autumn/blob/main/.github/workflows/delete_preview.yml
- PRをcloseしたときに起動するワークフロー
-
https://github.com/GoCon/2021autumn/blob/main/.github/actions/get_preview_repo/action.yml
- プレビュー用のリポジトリの名称を組み立てる処理を切り出したcustom action
詳細といいつつ説明が雑になってしまった。元ネタのブログは丁寧に説明していて偉い。
legacy-octobay-app(元ネタ)との主な違い
- Personal Access Token (PAT) ではなくGitHub Appsを使う
- PATは権限が強すぎる(特定のorganizationだけに権限を制約できない)点と、持ち主のユーザーがorganizationを抜けると使えなくなる点がネックだった
- GitHub Appsを使うとトークンからAPIキーを取得する処理を毎度書かないといけないのが少し面倒ではある
- プレビュー用のリポジトリは専用のorganizationの下に作る
- GitHub Appsの権限は専用のorganizationに限定されるので、万一トークンが漏洩しても本番環境の権限は安全に保たれる
- メインのorganizationがごちゃごちゃするのも避けられる
- ちなみに1人のユーザーが作れるorganizationの数に明確な上限はなさそう
- https://webapps.stackexchange.com/a/37560
- GitHubにめちゃくちゃな負荷をかけたりしなければ問題ないらしい
- GitHubのAPIアクセスには
octokit/request-action@v2.x
を使う- legacy-octobay-appではリポジトリの操作ごとに独自のcustom actionを実装している
- 単にAPIを呼ぶだけなら
octokit/request-action
のほうがベタッと書けて挙動も把握しやすいので便利そう
- プレビュー環境を立てたらPRにコメントをつける
- GitHub PagesをAPIを叩いて明示的に有効にしている
- 通常は
gh-pages
にpushすると自動的に有効になるんだけど、初回のpushでは有効にならないっぽい
- 通常は
感想、気になってること
- わりと便利な気はする
- 「こんな感じでいいか見てもらえますか?」というのが楽にできるようになった
- 手元で十分に検証している小さな変更では動かす必要がない
-
preview
ラベルが付いているときだけ動かす、みたいな感じでもいいかも
-
- GitHub Pagesへの反映処理が終わらず、いつまでも404のままになることがある
-
gh-pages
に何かコミットすると反映される
-
- プレビュー環境のURLの通知の方法は調べてみるといろいろある
- 設定ファイルが200行以上になってしまった
- 長い!
- これを人に引き継いでしまっていいのだろうかという若干のためらいがある
- GitHub Actionsとして実装する範囲をやや超えているような気もする
Discussion