エディタ：GitHub Pages上でPRプレビューを実装する

[sevenc-nanashi]

2024/11/16：実装しました 🎉

• 表示側リポ：https://github.com/VOICEVOX/preview-pages
• 表示ページ：https://voicevox.github.io/preview-pages/
• 更新のWorkflow：https://github.com/VOICEVOX/voicevox/actions/workflows/DANGEROUS_trigger_preview_pages.yml

---

内容

エディタでPRを出すとPRの内容（Storybookやブラウザ版）が表示されるやつを実装したいです。

Pros 良くなる点

レビューがしやすくなる

Cons 悪くなる点

複雑になりそう

実現方法

https://github.com/sevenc-nanashi/vv-preview-demo-page
https://github.com/sevenc-nanashi/vv-preview-demo-bot
やってみました。

• page：
  • pull_requestでartifactをビルドする
  • pull_request_targetでdemo-botを発火させる
• bot：
  • workflow_dispatchでプルリク一覧とビルド済みのArtifactを収集してPagesにあげる

みたいな感じです。

その他

（なし）

[Hiroshiba]

issue作成ありがとうございます！
メンテナ視点からちょっと補足説明させていただきます 🙏 　（メモと、他の方への共有を兼ねて。）

目的

プルリクごとにブラウザ版エディタやStoryook等の専用静的ページを作り、レビューをしやすくして開発効率を高めるのが主目的です。
（あと楽しそう。）

手段

パッと思いつく方法はNetlify等ですが、こちらは価格的にスケールが難しそうだと判断しました。
OSSまともに稼働するためにはチームでの開発になりますが、１人月３０００円で大変です。
あと誰でもは参加できないので、折衷案としてGithub Pagesで開発する方針となっています。
（試してくださった @sevenc-nanashi さんに感謝です！！！）

展望

汎用的な形にできれば、VOICEVOXエディタ以外でもとても有用なフレームワークになるのではと個人的に期待しています。

[Hiroshiba]

@sevenc-nanashi 少し見させていただきました！
仕様として気になる点をいくつか･･･！

1. -pageと-botはどっちがVOICEVOX/voicevox想定で、どっちがどのリポジトリを想定してますか 👀
   • たぶんpageがVOICEVOX/voicevox、botがgithub pagesをデプロイする先？
2. page側で、build_page.ymlとtrigger_bot.ymlが同時実行される、つまりpushされたものがビルドされ終わる前にbotが走り始めそう？
3. これプルリク時にbot側からpageのartifact見れるのかな
   • 試してないんでしたっけ。PR作ってみます！

📝 とりあえず全体のworkflowを眺めました

[sevenc-nanashi]

1. -pageと-botはどっちがVOICEVOX/voicevox想定で、どっちがどのリポジトリを想定してますか 👀

-pageがvoicevox/voicevox、-botがvoicevox/editor-preview（仮称）ですね。

2. page側で、build_page.ymlとtrigger_bot.ymlが同時実行される、つまりpushされたものがビルドされ終わる前にbotが走り始めそう？

はい。そういう前提でコードを書いています（Artifactができるのを待機）

3. これプルリク時にbot側からpageのartifact見れるのかな

というと？GitHub APIではアクセスできますね。

[Hiroshiba]

3. これプルリク時にbot側からpageのartifact見れるのかな

というと？GitHub APIではアクセスできますね。

（もう直ってそうですがメモとして）
on: pushだったので、fork先リポジトリにはartifactができるけどfork元リポジトリにはできないはずで、だとすると権限がないだろうな〜と思った次第でした！

[Hiroshiba]

2. page側で、build_page.ymlとtrigger_bot.ymlが同時実行される、つまりpushされたものがビルドされ終わる前にbotが走り始めそう？

はい。そういう前提でコードを書いています（Artifactができるのを待機）

おーなるほどです！
artifactが正常に作られなかった場合とかも大丈夫そうでしょうか。
デプロイ用のコンテナが起動しっぱなしになっちゃうので。

まあでもそこ含めてコード読むとわかりそう！！
読んでってみます！

[Hiroshiba]

チェックしたい項目メモ

• PRがcloseするとページが消えるか
  • 消える。即時かどうかわからないけど。
• actionsとして切り出しが可能か（マストではない、だいぶ複雑になりそうならactionsにするのもありかもくらいの気持ち）

[sevenc-nanashi]

artifactが正常に作られなかった場合とかも大丈夫そうでしょうか。
デプロイ用のコンテナが起動しっぱなしになっちゃうので。

Jobが失敗落ちしたらArtifactを取らないようにしています。

これ、初回コントリビュータの承認待機がしんどいですね…cronあたりで追加で10分おきに回して差分があったらデプロイするようにしてもいいかもしれない？

[Hiroshiba]

ちょっと提案です！！　まだ考えきれてないので穴あるかもですが！

PRごとに全artifactを総なめするpull型ではなく、push型にするのはどうでしょう？ 👀

今のロジックはこうだと想像してます：

• PRが送られてくるリポジトリA（-page）
• ページを配置したいリポジトリB（-bot）

1. AにPRがpushされる
2. Aでページをビルドし、Aにartifactを配置する
3. ↑と同時に、AがBのartifact収集workflowを回す
4. Bは2が終わるかエラーになるまで待機
5. Bのgithub pagesにpush
6. AのPRがcloseされる
7. AがBのworkflowを回す
8. Bがgithub pagesから削除（未確認）

これをpush型にするとこうなりそう：

1. AにPRがpushされる
2. Aでページをビルドし、Aにartifactを配置する
3. ↑の完了後、AがBのartifact回収workflowを回す
   • リポジトリ名・PR番号・artifactのid？（・デプロイ先のサブディレクトリ）を引数で渡す
4. Bのgithub pagesにpush
5. AのPRがcloseされる
6. AがBのworkflowを回す
   • リポジトリ名・PR番号を引数で渡す
7. Bがgithub pagesから削除（未確認）

push型の利点はビルドが終わった後にデプロイを開始できる点だと思います。
あとworkflow_dispatchで作成や削除を自由に実行できたり、他のリポジトリを追加する時にコード変更が不要だったり、パラレルに複数動かせたり、デプロイコードを不要にできるかもです。

欠点は作成・削除用２つのworkflowが必要なこと、on: pull_requestからon: pull_request_targetを呼べるか不明なこと（できるんだろうか。。。）とか･･･？
（追記：後者、無理な気がする。。）

そもそも超荒業として、リポジトリAからリポジトリBへ直接git pushしちゃう手もあるかもです。
これだと多分Bからworkflowをなくせるかも･･･？？

ちょっと色々精査してないので粗いかもですが、一旦アイデアまで！！

[Hiroshiba]

↑で提案したpush型の方法ですが、おそらくPRを出した側でビルドした後、fork元（target）側でワークフローを発火させる必要があるのですが、その手法がGithub側に用意されてなさそうでした 😇
なのでpull型で作るしかなさそう！！

[sevenc-nanashi]

on: pull_requestからon: pull_request_targetを呼べるか不明なこと（できるんだろうか。。。）とか･･･？

無理だと思います...
基本的にWriteアクセスはやすやすと与えられないような設計を感じるので、それをGitHub公式が実装するのはかなり考えづらいです。

[Hiroshiba]

ですよね。。 😇
よし、 @sevenc-nanashi さんの実装を基軸に進めて行けると良さそう！！！

ちょっと設計を議論したく、いくつか質問させてください！

1. actionsに切り出しはできそう？
   • 切り出せれば、いろんな人が使えたり、PRもらいやすかったり、 @sevenc-nanashi さん自身別のとこでもサクッと使えると便利そうだと思ったので
   • 別にマストではないはず
2. 1が行ける場合、actionは１つにできそう？
   • 今page→botに通知するworkflowと、bot側のworkflowの２つがあるはず
   • これをひとまとめにできそう･･･？
3. 2が行ける場合、page側にactionを導入するだけにできそう？
   • これができれば、「push用のリポジトリを作って、PR用ページを作りたいリポジトリ側だけの変更すれば完了」になるので相当使いやすい
   • でも権限周りが難しそうな予感

[sevenc-nanashi]

actionsに切り出しはできそう？

ちょっとやっていましたが、かなり面倒（例えばブランチのフィルタのパーサーを作るとか...）なのでパスしたいです...

[Hiroshiba]

なるほどです！！！ 無念！！！
運用してみて何か良い方法を思いついたらActionsにするとかもありかもですね！
（ちなみに何でフィルターがいるんでしょう 👀 　元リポジトリのrelease-*とmain以外のプレビューページを作らないためとか･･･？）

１点気になったのですが、artifactの期限が切れるとページが作られない感じでしょうか 👀
最大期限は90日にできるので期限切れでページが表示されないのは良さそう。エラーになると困りそう！

---

アーキテクチャの更新とかってまだ思いついたりされますか 👀
もし一旦これが最高そうであれば、この形で進められればと思ってます！！

進め方として今考えてるのは、previewページリリース用のリポジトリの設定権限を @sevenc-nanashi さんにも付与し、メンテナンスをほぼ完全にお任せするとかだとやりやすいのかな～とか思ってたりします！
多分トークンとか色々設定が必要そうだな～と。

フレームワークやライブラリの選定も自由で･･･！
一応癖のないライブラリや大体の効くものであれば、いざという時にメンテナンスできるのでありがたくあります 🙏
ちなみに、硬いコードを書くときのライブラリの選定基準のガイドラインがあるのでもしご興味あれば！

[sevenc-nanashi]

（ちなみに何でフィルターがいるんでしょう 👀 　元リポジトリのrelease-*とmain以外のプレビューページを作らないためとか･･･？）

元だと、project-*とmainとプルリクのプレビューを作るようになってましたが、例えば：

• project/*にしたかったり
• プルリクは省きたかったり
• 最新5件だけにしたかったり

とか色々とカスタマイズしたいと思うんですよね。それをactionsの引数で実装するのが面倒だなぁ…と。

１点気になったのですが、artifactの期限が切れるとページが作られない感じでしょうか 👀

多分作られなくなりますね。でもエラーで全体が死ぬことはないはず。

[Hiroshiba]

なるほどです！！
フィルタは正規表現にする形にしておけば実装もそんなに難しくないかもとかちょっと思いました。
でもActions実装はマストじゃないと思います！

このコメントの後半のこちらはどうでしょう 👀
とりあえず進めてみるとかでももちろんOKです！　合図いただければリポジトリ作ります 🙏
名称何にしようかな。

アーキテクチャの更新とかってまだ思いついたりされますか 👀
もし一旦これが最高そうであれば、この形で進められればと思ってます！！

進め方として今考えてるのは、previewページリリース用のリポジトリの設定権限を @sevenc-nanashi さんにも付与し、メンテナンスをほぼ完全にお任せするとかだとやりやすいのかな～とか思ってたりします！
多分トークンとか色々設定が必要そうだな～と。

フレームワークやライブラリの選定も自由で･･･！
一応癖のないライブラリや大体の効くものであれば、いざという時にメンテナンスできるのでありがたくあります 🙏
ちなみに、硬いコードを書くときのライブラリの選定基準のガイドラインがあるのでもしご興味あれば！

[sevenc-nanashi]

とりあえず進めてみる

現在進行形で進めてますね。
とりあえずeditor-previewって名前にしようと思っています。

（あと何故か自分にリポ作成権限がありました）

[Hiroshiba]

なるほどです！！楽しみ！！

名称について、ちょっと将来的にいろんなリポジトリのプレビューを担えないかと思ってたりするので、ちょっと汎用めの名前にしたいかもです…！！
プレビューページ作成を1リポジトリにしとくと、artifact収集コードの管理が楽なので。
ちなみにeditor以外だとblogとかが候補かなと。

なので一旦editor専用じゃない名前だとありがたいかもです！！
previewを名前に入れるの分かりやすそう。
preview-pagesとか…？

リポジトリは作っちゃっていただいてもOKです！
権限周りやリポジトリ保護等はこちらで設定します🙏

他のリポジトリと揃えて、mainブランチへの直接のコミットはせず、プルリクベースで進める感じで良いでしょうか？
あるいは最初動くまではmainに直接pushでも良いかも。そして完成したら履歴全部消してinitial commitをforce pushしてそこからPRベースにするとかでも…！！

なるべくやりやすい形で進められれば🙏

[sevenc-nanashi]

自分のフォークで動くまでやった後にPull RequestのSquash MergeをInitial Commitみたいにする、でやろうと思います。

[Hiroshiba]

導入のためにやること・やったことのメモをここに残していこうと思います 🙏

まずはGithub App作成します！

[Hiroshiba]

Github Appを作り、VOICEVOX Orgにインストールしました。
VOICEVOX/voicevoxにのみ許可を与えてます。

[Hiroshiba]

preview-pages内にsecretsも４つとも作成しました。
既存のものはわかりやすいように削除しました。
これでpreview-pages側はOKなはず！

[Hiroshiba]

VOICEVOX/voicevox側の作業に入りました。

TRIGGER_PREVIEW_PAGES_TOKENを設定します。（この説明がpreview-pages側にあったほうが良いかも）
preview-pagesへのWorkflowsのR&Wを許可したトークンをVOICEVOX/voicevoxにセットしました。

preview-pages側のワークフローが落ちてますが、とりあえず準備できたのでVOICEVOX/voicevox側のPRをマージします！

[Hiroshiba]

pages周りで落ちてそう。そういえば許可与えないといけなそう、Settingsを見直します。

[sevenc-nanashi]

voicevox/preview-pages：
Pagesのビルドのオプションを間違えていたので修正（ブランチからデプロイ -> Actionsからデプロイ）

[Hiroshiba]

VOICEVOX/voicevox側のtriggerが落ちてそう。なんでだろ、調べます！
workflowのR&Wだけじゃダメだったりするのかな。
https://github.com/VOICEVOX/voicevox/actions/runs/11698731079/job/32579503800

[Hiroshiba]

うーーーーーーん　PATの設定は雰囲気合ってる気がする

それをちゃんとVOICEVOX/voicevoxに設定できていそうではある

コピペミスった可能性あるかな･･･。再設定してみます。

[Hiroshiba]

うーーーーん詰んだ！！！
Organizationだとworkflow dispatchに制限があるとか･･･････？

[Hiroshiba]

voicevox/preview-pagesってなってるけど、VOICEVOX/preview-pagesじゃないとダメだったりする･･･？

あとはupdate_pages.yml側が

permissions:
  contents: read
  pages: write
  id-token: write

になってるけど、このパーミッションがTRIGGER_PREVIEW_PAGES_TOKEN側に必要とか･･･？

[Hiroshiba]

お、まわりました！

Actionsへの権限が必要だったっぽいです。たぶんwrite権限。
確かに説明はこうなってるので、合ってそう。

Actions
Workflows, workflow runs and artifacts.

ちなみにWorkflowsの説明

Workflows
Update GitHub Action workflow files.

[Hiroshiba]

mainブランチのbuildは成功してそうですが
https://github.com/VOICEVOX/voicevox/actions/runs/11698731082

収集に失敗してそう･･･？
https://github.com/VOICEVOX/preview-pages/actions/runs/11699103159/job/32580492466

2024-11-06 07:33:03.281 +00 info app·Branch main: No build check found

[Hiroshiba]

artifactにアクセスするにはまた別の権限が必要だったりとか･･･？

[sevenc-nanashi]

普通に名前をミスっていました...

[Hiroshiba]

うーーーんどこが原因だぁ
https://github.com/VOICEVOX/preview-pages/actions/runs/11699304255/job/32581048596

ちょっとartifactのread権限付けてみます。
（たしか非ログインだとartifactダウンロードできないので気になってる）

[Hiroshiba]

artifactsはActions権限っぽいので付けてみました

https://github.com/VOICEVOX/preview-pages/actions/runs/11699304255/job/32581144789

2024-11-06 07:52:43.345 +00 info app·Branch main: No build check found

うーーーーむダメそう。権限戻します。。

[sevenc-nanashi]

どうやらWorkflowの名前じゃ無くJobの名前（i.e.：jobs: 下のキー）だったようです...

VOICEVOX/voicevox#2343

[Hiroshiba]

おー通知まで進みましたね！！！
通知されるリンクが違うかもですが･･･！！

[sevenc-nanashi]

プレビューとか色々を直しました：VOICEVOX/preview-pages#5

[Hiroshiba]

エディタの個別ページ見れましたね！！！あとちょい！！！

リスト一覧が表示できてないかも･･･！
https://voicevox.github.io/preview-pages/

https://voicevox.github.io/preview-pagespreview/downloads.json 404 (Not Found)
というエラーが。

[Hiroshiba]

動いたー！！！！！！　良い感じ！！！

[Hiroshiba]

@sevenc-nanashi
プレビューページ、安定稼働してそうですね！！！

ということでタスクは完了かなと思いました、お疲れ様でした！！実装ありがとうございました！！！

今回も良い機能が実装できたということで、こんな感じで SNS にツイートしたいと思っています！
何か問題やコメントあればぜひぜひ 🙏

#VOICEVOX開発状況 
プルリクエストごとにプレビューページが作られるようになり、その時点でのエディタやStorybookがブラウザで確認できるようになりました🎉（ソフトウェアの見た目には影響ありませんが、開発が楽しくなりました。）
【開発者:@sevenc_nanashi】
https://github.com/VOICEVOX/preview-pages

あ、あとこのissueは数年間の間に何度も参照すると思います！
なのでポータル的にいろんな URL をdescription内に貼っていただけると助かります 🙏

と言ってもリポジトリとプレビューURLと、あとはVOICEVOX/voiecvoxのtrigger workflowくらい･･･？

その変更と、このissueのクローズをもってプロジェクトの完了とさせていただければと！！
再度、ありがとうございました！！

[sevenc-nanashi]

一番上に書き足したのでCloseします。おつ！

[Hiroshiba]

ツイートさせていただきました！！ https://x.com/voicevox_pj/status/1857625465680441836