https://github.com/zoldof/algo-notes-ci/tree/main
https://github.com/zoldof/algo-notes/tree/main
https://zoldof.github.io/algo-notes-ci/?dname=test
https://zoldof.github.io/algo-notes/test/
◆結局なんのために作ったものか？
ページの編集とプレビューと投稿を意図的に処理分けして見直し工程を明確化したい
その中でできる限りビルド速度は速くしたい
数式に対応した投稿プラットフォームを自前で用意して、ページの挙動も理解したかったし、UIの面で自分好みにできるのが強みとの思いからページ作成に至る
◆サイト修正
・動機としてはページのテストにあたりビルド時間を削減したい
・・そもそもプレビューしてから投稿できる仕組みだけでいいのでは？
・↑自身としては都度投稿して全体像を確認する方がページごとの管理がしやすい
・↑ひとつ段階を得られるという意味合いと、テスト段階のページを「成果物想定」との認識で評価できるため
・Githubの機能面の理解を深める
・・htmlの1枚ものから作成開始
・・機能複雑化に伴いmain.jsとstyle.cssを分けた
・fetchやjekyllの理解と使い方（特にfetch）
・・DOMを待つであるとか構造の話
・テストについてクエリ呼び出しでのファイル運用
・・pyodideで使った知識を活用
・txtとmdの区別およびmarkedとkramdownの理解
・・noindexのフロントマター指定
・・GFMについて検索
・・_layouts/default.htmlによる使いまわし
・・_config.ymlでビルド時のMarkdownを指定
・jekyllの深掘り
・KaTeXのレンダリング処理とMathjaxの導入試験
・・katex.jsの作成
・_includes/head.htmlによるhtml（KaTeXのCDN）の部分的挿入
・workflowsをPagesのActions設定により取得［Jekyll，Static］
・キャッシュはビルド設定で保存する仕組みにもできる
・ブラウザ側のキャッシュはビルド構成にmoduleタイプのjsが含まれる場合は更新される可能性がある
・・各動作を調査
・パス構造の理解と修正
・自分用ページを作りたいとの意図でPVを分ける目的を持ったが、解析ツールで設定することとした
・一様はテストページ（Static）とビルドページ（Jekyll）で分けられる形にはなった
◆課題と解決
・課題1：ブランチによるテストとビルドの使い分け？
・・解決：Pages的には逐次複製的な位置付けでデフォルトのbuild & deployであれば指定はできるが、マージ時はディレクトリツリーが同一となっている必要がある
・試行錯誤履歴：［test］test.html ⇔ ［main］
・・こちらはパス構造ではないので気を付ける
・・意図はそれぞれ［テスト，ビルド用］
・・テスト表示だとフロントマターは残存する
・・デフォルトビルド後は、一時的にテスト表示ができなくなる場合がある
・・おそらく使用したいファイルがビルドによって扱えなくなる
・・［test］でテスト［main］でビルドの流れを把握しつつ、各ファイルの更新と開発段階に合わせて柔軟にデフォルトブランチを変更する手筈になっている
・課題2：テストページをStaticビルドするとビルドページが404になる
・・解決：404ページで該当クエリを使用したテストページを表示する仕組みに変更
・課題3：build & deployでは重いし毎回発火のためにコミットが必要
・・解決：JekyllのActionsをこの時点で導入
・課題4：表示自体には問題ないが検索評価についてテスト中にビルドページを404からのテストミラーでは不足との判断
・・検討1：JekyllのActionsだけでビルド時間かからないなら、そもそもテストページは不要？
・・結果：時間かかるのでテストページ必要でStaticとは用途も違うがpush対象のブランチ指定は外してボタン始動とした
・・検討2：txtとmdを分けて運用すればビルド時の衝突が無くなるのではないか？
・・結果：確かに分けているとJekyllビルドしてもテストページ側（txt）は表示されるようになったが、逆のStaticビルド時はどうにもならずStaticビルドでビルドページ側（md）を反映するのは無理があると判明
↑mdmd運用でテストページも表示するのは無理で、理由としてはJekyllビルド時にmdがhtmlの実体に変換され不可視になり参照できなくなるため
◆CI/CD：別リポジトリに成果物を出す仕組みの導入へ向けて修正開始
・リポジトリ名の変更
・txt → Static → md作成 → Jekyll → html成果物を別リポジトリへ作成 → ［テストページ，公開版］の同時公開
・Staticビルドする限りはクエリ設定がどうであれJekyllビルドが成果物認定できない状態のため、どちらにしても分化が必要だがビルドという概念とクエリはブラウザが持っているのに、ビルド側で保管できるとの勘違い
・・あと呼び出しも可能だけど、ここでは意味がない
◆別リポ成果物出力の修正開始に向けてコード簡略化をしたい
・課題1：markedとkramdownをどちらかに統一できないか？
・・解決：それぞれビルド前提が違うため無理で、今回の設計意図からするとテストは速くしたいし、成果物も素早く表示してほしいからコードを分ける必要がある
・課題1：index.htmlを仮想でdefault.htmlから生成してクエリ適用すればいいのでは？
・・解決：そもそもの課題設定が間違っていて本来の「テストページを使いたい」という意義を失う
・課題2：コードがほぼ同じなのでdefault.htmlにindex.html（テストページ）の内容を流用できるか？
・・検討済1：ビルド前提であれば難しい
・・検討済2：サーバー依存であれば可能だがPagesでは基本的に使えない
・・検討中3fetchでhtmlを読み込む形はSEOに影響するが可能ではある？
・・検討中4ツール前提であれば可能？Pythonで？
・課題3：パス構造を初期設定して関数でまとめておく？
・・解決：これはhtml上でbaseを設定すれば可能でscriptで設定すればjekyllビルド時のjsファイル内のパス指定でsub/dir/を制限することも可能。base設定は有用でjs側でimportする場合にbaseなしで「ルートのファイルだ」との認識で「"main.js"」のように指定してしまうとjs側では「モジュールですか？」と誤認してしまうから。さらに言うと、base設定しても「"main.js"」だけだとimportさんは「やはりモジュールですよね？」と認識してしまうので省略せずに「"./main.js"だよ。リポ直下のファイルですよ！」と伝えると「あぁぁ、なるほど」と分かってくれる
◆staticのビルド速度向上
・軽量ランナー：❌
・並列実行：❌
・セルフホスト：❌
・必要なファイルのみアップロード：❌
・キャッシュの設定：❌
・開発目標設定
・・ビルド成果物を別リポジトリへ出力することによってテストページとの分離に成功
・・・同一リポジトリ内でもファイルを分けたら可能ではあったかもだが、分けてしまうと本来のテストの意味がなくなる
・・style.cssを圧縮していればjkyllのassets読み込まない設定？
・・・configのexcludeで対応