前提
- GitHub Pages にメディアサイト？は作成済み。
- アプリと記事関連ファイルを同一リポジトリで管理している。
- したがって、記事のみを更新・公開したいときでも、同じリポジトリを触る必要がある。
- 具体的にはAngular のpublic フォルダに記事関連ファイルをコピペし、commit &push &merge が必要。
詳しくは前々々回記事参照
問題点と解決策
問題点：
- 1つのリポジトリでアプリと記事関連ファイルの2つの管理をしていること。(実は利点もあってダメと決めつけるのは思い込み)
- 記事公開時に手作業が発生していること。
解決策：
- 記事関連ファイルは別リポジトリへ切り離し、submodule化する。
- 記事公開用のGitHub Actions を作成し、記事公開作業を自動化する。
なのでやらねばならない...
(というのは建前でほんとはGit submodule と GitHub Actions 使いたい!)
記事関連ファイルのsubmodule 化
そもそもsubmodule とはどういう仕組みなのか
参考サイトは以下の4つ。
理解としては
- submodule を使うことで、あるリポジトリの中で別リポジトリ(以降子リポジトリ)の断面を持つことができる。(入れ子構造にできる。)
- 子リポジトリの断面はcommit ベースなので、好きな断面を指定できる。(branch の制約なし。)
- 子リポジトリの断面の切り替えは明示的にコマンド打たないとだめ。
ここまでは思っていたのと雰囲気が近かった。
しかし、参考サイトを見る中で意外なことが分かった。
別にリポジトリ分けることは必須ではない
こちらは意外でした。
(私が知らなかっただけで結構前から話題だったっぽい。)
ちょっと調べてみましたが、
リポジトリ1個の時と複数の時とそれぞれ長所短所あるよ！
状況に合わせて長所を生かす運営をすることが大事だよ！
ってことらしい。
何も考えずリポジトリ分けようとしてごめんね。
熟考した結果...
私のケースでは分けた方がよいと判断しました。
理由は...Git submodule と GitHub Actions 使いたいからです！
いろいろ
あまり書く程の事はないので箇条書きで。
- 記事関連ファイルをGitHub に格納
- 記事を置きたい場所で
git submodule add https://github.com/magurouhiru/article.git - リポジトリ名ミスったのでパス変更して
OKと思ったら2点問題が。
1点目は.git と.gitignore ファイルがビルド後に入ってた。
なんか嫌だったので調べたら同じ質問している人がいた。
書いてある通りangular.json のassets でignore に指定してやれば消えてくれた。
2点目はビルドしたら警告が出た。
"C:\Program Files\nodejs\npm.cmd" run build
> mysite@0.2.1 build
> ng build --base-href /mysite/
Initial chunk files | Names | Raw size | Estimated transfer size
main-VVGHZWNN.js | main | 338.54 kB | 89.57 kB
styles-RWIYYJCX.css | styles | 186.83 kB | 19.38 kB
polyfills-SCHOHYNV.js | polyfills | 34.52 kB | 11.29 kB
| Initial total | 559.90 kB | 120.24 kB
Application bundle generation complete. [2.857 seconds]
▲ [WARNING] bundle initial exceeded maximum budget. Budget 512.00 kB was not met by 47.90 kB with a total of 559.90 kB.
Output location: C:\Users\elect\Desktop\app\intellij_idea\mysite\dist\mysite
Process finished with exit code 0
ファイルサイズが大きすぎるよ！と怒られてしまった。
(まあ普通はこんなことしないよね。)
調べたら、こちらもangular.json の設定を変えればいいらしい。
maximumWarning を変えたら怒られなくなった。
記事にある通り、本来はよくないけど...
GitHub Actions の変更
といっても↓記事がとても優秀だったので必要な箇所だけ抜き出して適応する。
ポイントは↓2点
- actions/checkout@v4 に
submodules: recursiveを渡す。 -
run: git submodule update --remote --recursiveで最新の記事を落とす。
なお、git submodule update 後のコミットは今回は不要なのでしない。
途中ミスもあったけど、この書きかけの記事で更新できるかやって見た結果。
理由は↓前回記事で追加したメタデータ処理です。
なんとエラー処理してないため、メタデータがないと動かないのです！
まあGitHub Actions がちゃんと動いたことが分かったからOK！
まとめ
たのしかった
当初の目的(Git submodule と GitHub Actions 使いたい!)は達成できたのでOK
あとリポジトリを分割するしないも考える要素があると学んだ。
今回の記事は以上です。
前回記事はこちら
詳細見たい人はこちら