この記事自体が、Codex Cloudから公開するために作成したテスト記事です。いつもの日次AI記事とは別に、クラウド上で書いた文章が、このブログまで届くかを確かめています。

記事がブログに届くまで

このブログの記事は、Markdownという文字中心のファイルで保存しています。見出しや箇条書きを書いたファイルを、Jekyllという仕組みがWebページに変換します。

今回の公開テストでは、次の順番で記事を送ります。

  1. Codex Cloudの作業環境で記事を書き、site/_posts/ に保存します。
  2. 公開前にJekyllでページを生成し、既存のテストと記事の表示内容を確認します。
  3. 問題がなければ、この記事のファイルだけをGitでcommitします。commitは、変更内容を記録する操作です。
  4. GitHubのmainブランチへpushします。pushは、その記録をGitHubへ送る操作です。
  5. GitHub Actionsが変更を受け取り、Jekyllでサイトをbuildします。
  6. 生成されたサイトをGitHub Pagesへdeployし、yuduki-glass.comで読める状態にします。

GitHub ActionsはGitHub上で処理を実行する仕組み、GitHub Pagesは生成されたページを配信する仕組みです。記事を送ったあとのビルドと公開は、既存のワークフローが担当します。

手元のPCに頼らず進める

今回、記事の作成と公開前の確認はCodex Cloudで行います。その先もGitHub上で処理するので、この公開経路のために自宅のPCを起動し続ける必要はありません。

ただし、今回確認するのは、依頼した1本の記事をクラウドから公開できるかという点です。毎日決まった時刻に記事を書く定期実行が設定された、という意味ではありません。

公開できたかは、画面の内容まで確かめる

GitHubへ送れただけでは、ブログで読めるとは限りません。ビルドやdeployが失敗したり、記事の日付・URLの指定が合っていなかったりする可能性があります。

そのため、今回の確認では、GitHub上の変更履歴、GitHub Actionsの結果、そして公開URLに表示される本文を順番に確認します。この記事が読めても、それだけで自動化全体の結果を断定せず、対応する実行記録と合わせて判断します。

今回のテストで変更するもの

追加するのは、この公開テスト記事1本だけです。既存の日次記事、サイトの設定、GitHub Actionsの設定は変更しません。外部の生成AI APIやPersonal Access Tokenも使用しません。

このページを通じて、クラウドで作った文章がGitHub、Jekyll、GitHub Pagesを経由して読者に届く流れを確認します。

この記事はCodex Cloudによる公開経路確認のために作成したテスト記事です。