変更が公開されたあとに起こること

ipe.rest への変更は、GitHub 上の短いワークフローを通って訪問者に届きます。サイトをコピーし、確認し、公開し、何が新しいかを検索エンジンに知らせます。ほとんどの実行は40秒以内に終わります。

前の記事は、ページがどう作られるかを書きました。今回は、その終わりから始まります。変更が私たちのリポジトリの main ブランチに届いたときです。数値は2026年11月10日のもので、ワークフローのファイル、サイトのローカルでのビルド、そして GitHub での直近8回の実行から取りました。

コピー

サイトは素のファイルなので、最初の手順はコピーです。ワークフローはリポジトリをチェックアウトし、訪問者に必要ないもの以外をすべてコピーします。必要ないものとは、スクリプト、テスト、ワークフロー自身、バージョン管理のデータ、そしてすべての Markdown ファイルです。リポジトリにある586個のファイルのうち、329個がサイトのフォルダに入り、約10 MB になります。

確認

次に、7個のテストがそのフォルダに対して動きます。リポジトリに対してではありません。見るのは、訪問者が必要とするファイル、たとえば robots ファイル、サイトマップ、サービスワーカー、ホームページがあること。scripts や tests のように、あってはならないフォルダがないこと。そして404ページに noindex が付き、ホームへのリンクがあることです。失敗するとワークフローはここで止まります。何も公開されず、以前のバージョンが公開されたままになります。

公開

次に、フォルダがアップロードされ、配信を担う GitHub Pages に渡されます。デプロイは同時に1つしか動きません。1つが動いている間に新しい変更が届くと、古い実行は取り消されます。間に私たちのサーバーはなく、データベースもありません。サービスワーカーのバージョンが変わると、訪問者のブラウザは新しいキャッシュをインストールし、あとの訪問で古いものを削除します。

知らせる

公開したあと、ワークフローは IndexNow に、サイトマップの日付が韓国時間で今日になっているページのアドレスを送ります。IndexNow は Bing、Naver、Yandex などの検索エンジンが受け付けるプロトコルです。必要なキーは、サイトのルートにある公開のテキストファイルです。この手順は失敗してもかまいません。失敗しても、デプロイは成功として数えられます。

これまでの実績

直近8回の実行のうち、7回が成功し1回が失敗しました。その22秒後の次の実行は成功でした。成功した7回のうち5回は40秒以内で、最も遅いものは2分18秒でした。実行の開始から最後の更新までを測ったので、時間はおおよそのものとして読んでください。

緑の実行が語らないこと

実行が通ったということは、ファイルが届き、7個の確認に通ったということです。小さなスマートフォンの画面でページが正しく見えるかどうかは語りません。また IndexNow は検索エンジンに知らせるだけで、いつ、あるいはページが掲載されるかどうかについては何も約束しません。

ipe(); // copy, check, publish, tell

ワークフローは意図的に短くしています。手順が少ないほど、静かなサイトが壊れる場所も少なくなります。