pull request preview action の導入 #569
Open
+45
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About
PRごとにビルド結果をpreviewするアクションを導入してみます。
https://x.com/neko314_/status/1890755774680351004
モノとしては、 https://github.com/rossjrw/pr-preview-action を利用していて、まだ初期バージョンなのでちょっと荒削りながらだいたい動いてくれるんで、まあこれでいいんじゃないかな、と思ってます。
この pr-preview-action ってやつは、デフォルトでは同一リポジトリ内のどっかにプレビュー用のコンテンツをpushしてくれる、っていう単純な作りになってるんですが、GitHub Pages の場合は、1つのリポジトリには1つの名前(ドメイン名)しかつけられないので、それだとうまくいかないような気がしていて、そこで、rubima organization配下に、previewをデプロイするためだけの新たなリポジトリを作って、そちらにpushするようにしています。
という具合に、ちょっとだけ構成が無駄に複雑になってるところはあるんですが、そのぶんpreviewのゴチャゴチャでproductionのるびまが汚されたり、なんかの間違いでproductionのコンテンツをぶっ壊しちゃったり、みたいなことがなくなって、安全に運用できるはずです。
Action詳細
さて、このアクションの処理の流れとしては、ざっくり以下のようになっています。
このうち、2と4は少しトリッキーなのでちょっと説明すると、まず2のコードは actions/checkout#438 (comment) から拾ってきました。actions/checkout にデフォルトでこの機能が入ってないの不便だよなぁ、とは思いつつ、なんかだいぶアドホックな実装ではあるので、これに名前をつけたレベルのものを標準に取り込んでリリースするべきか、というと、ちょっと疑問かもしれません。とりあえずここではこれで動くといいな。
4はさらにアドホックで、writing_process.md とか script/checker.rb あたりから仕様を解読するにたぶんこんな感じだろうと推測してワンライナーを書き殴ってみたものになります。master から変更があったファイルたちの中から
articles/.*-号数-記事名.md
なファイル名を抜き出して、その号数-記事名
以外の画像ディレクトリを全て削除してて、article自体も消しといてもいいんだけど、そんなにデカくなさそうだからなんとなくそのまま残しちゃってます。なんかとりあえず力技でてきとうにゴリッと解決しました、という感じだし、shell scriptぢからがよわすぎてRubyに逃げてたりして、なんかすいません……とか思いつつ、まず仕様の解釈がこれで合ってるのか疑問だし、たぶんもっとキレイに書けるんじゃないかと思うので、識者のツッコミをお待ちしています。
あと最後に、5の工程で別repoにpushするためにGHの personal access token が必要で、いったん僕のアカウントで rubima/rubima-preview への write のみを許可した fine-graind なPATを作って、そいつをこっちのrepoの Actions secrets に、
PREVIEW_TOKEN
っていう名前で登録してあります。PATの賞味期限は1年に設定してあるので、1年後になんかpreviewが見れなくなったらこいつのことを思い出してあげてください。デプロイ先のディレクトリ構成
rubima/rubima-preview のほうがどういう状態になるかなんですが、rubima側にPRが立つごとにこのアクションが走って、rubima/rubima-previewリポジトリの gh-pages ブランチにビルド結果がpushされます。複数PRの結果を並行して保持したいので上書きしちゃったらダメなわけで、ルートディレクトリ直下に
みたいに、こっちのぷるりの番号に対応したサブディレクトリが掘られて、その中にpushされます。画像を全部こぴったら巨大になりすぎるのでPRで触ってる記事に関連してなさそうな画像は削除してからpushしてます、というのは上記のとおりです。
これは、特に削除する機能はどこにも実装されてないので、PRがマージされたりクローズされたりしても消えたりはしません。どうやって消すかはまた後日考えればいいかな、と。
制約(というかTODO)
rossjrw/pr-preview-action の現行バージョンにはひとつ残念な制約があって、READMEにも書かれてるんだけど、なんと、forkされたリポジトリからのPRに対してはpreviewが表示できません!
なにそれダメじゃん!って感じなんだけど、
とのことなので、v2のリリースを待つ。待っても出てこないようなら自力でなんとかする(同リポジトリの pull/6 から実装をこぴってきてなんとかする)。というTODOがあります。