😎

Pull RequestごとにGitHub Pagesでプレビューページを作る

2021/11/20に公開

やりたいこと

  • GitHub Pagesを使っているプロジェクトで、Pull Requestごとにプレビューページを自動作成したい

PRのコメントにプレビューページのURLが自動投稿されている様子
動いている様子

実装方針

  • GitHub ActionsでPRの作成ごとに一時的なリポジトリを作り、そのリポジトリのGitHub Pagesにプレビューページをデプロイする
  • PRがcloseされたらプレビュー用のリポジトリも削除する

元ネタはMultiple Environments With GitHub Pages | by Markus Kottländer | Geek Culture | Mediumです。基本的なアイデアはそのまま頂きました。実装の詳細をいくつか変更しています。(後述します)

実装の詳細

詳細といいつつ説明が雑になってしまった。元ネタのブログは丁寧に説明していて偉い。

legacy-octobay-app(元ネタ)との主な違い

  • Personal Access Token (PAT) ではなくGitHub Appsを使う
    • PATは権限が強すぎる(特定のorganizationだけに権限を制約できない)点と、持ち主のユーザーがorganizationを抜けると使えなくなる点がネックだった
    • GitHub Appsを使うとトークンからAPIキーを取得する処理を毎度書かないといけないのが少し面倒ではある
  • プレビュー用のリポジトリは専用のorganizationの下に作る
    • GitHub Appsの権限は専用のorganizationに限定されるので、万一トークンが漏洩しても本番環境の権限は安全に保たれる
    • メインのorganizationがごちゃごちゃするのも避けられる
    • ちなみに1人のユーザーが作れるorganizationの数に明確な上限はなさそう
  • 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