Cloudflare PagesでGitHub連携が古いまま止まった時の直し方

GitHubのremote変更だけでは足りない

Cloudflare Pagesは、GitHubと連携するとmainブランチへのpushで自動デプロイできます。通常はとても便利ですが、リポジトリ名変更や連携解除を挟むと、Cloudflare側が古い接続状態のまま残ることがあります。

今回も、ローカルのremoteは新しいGitHubリポジトリを向き、GitHub上のmainには最新commitがありました。しかしCloudflare Pagesのデプロイ履歴を見ると、最新commitが反映されていませんでした。

つまり、git pushは成功しているのに、本番だけ古い状態です。この場合、問題はGitではなく、Pages projectがどのGitHub repositoryを見ているかです。

Cloudflare Pagesの画面には「デプロイを作成する」というボタンがあります。名前だけ見ると、GitHubの最新commitを取り直してくれそうに見えます。

しかし、状態によってはHTMLやCSSなどをアップロードするDirect Upload画面に進みます。これはGitHub再接続ではなく、手元のファイルを直接アップロードして公開する方法です。

GitHub連携で運用しているメディアサイトをDirect Uploadに寄せると、本番とGit履歴の対応が分かりにくくなります。記事、sitemap、内部リンク、計測タグの確認プロセスともズレます。

Cloudflareのドキュメントでは、Direct Uploadで作ったPages projectは後からGit integrationへ切り替えられないと説明されています。GitHub連携で運用したい場合は、新しいPages projectを作る必要があります。

そのため、既存projectの中で再接続ボタンを探し続けるより、新しいPages projectをGitHub連携で作り直す方が早い場合があります。

静的サイトは手動アップロードでも一応動きます。しかし運用上は、どのcommitが本番なのかを追えることの方が重要です。

復旧は、まず新しいCloudflare Pages projectを作り、正しいGitHub repositoryを接続します。production branchはmainにします。

次に、新projectのpages.dev URLで表示を確認します。最新commitの内容が反映されているか、トップページ、sitemap、削除したページ、計測タグを見ます。

問題がなければ、旧projectからcustom domainを外し、新projectに本番ドメインを追加します。本番ドメインを動かすのは最後にした方が安全です。

見るべきなのは、GitHubに最新commitがあることだけではありません。Cloudflare Pagesのデプロイ履歴に、そのcommitのdeploymentがあることを確認します。

本番ドメインが旧projectに残っていないか、新projectがGitHub連携になっているか、production branchがmainかも確認します。

pushしたから本番も変わったはず、という思い込みが一番危険です。Cloudflare側のdeploymentを見て判断します。

Cloudflare Pagesは公開までは簡単ですが、実運用ではGitHub連携、Preview URL、Access、旧project整理を分けて考える必要があります。

大事なのは、見えているサイトがどのproject、どのrepository、どのbranch、どのcommitから出ているかを確認することです。