GitHub Actions で、記事を毎日1本ずつ自動公開する仕組みを動かしています。
その稼働確認で判定を間違えました。
原因は拍子抜けするほど単純だったのですが、間違え方のほうに学びがあったので書いておきます。
「成功しているのにコミットがない」という矛盾
朝、仕組みが動いたかを確認しようとしました。
- ローカルで
git logを見る → 公開のコミットが1本も増えていない - 公開待ちのファイルを置いてあるフォルダを見る → 先頭のファイルが残ったまま
- GitHub Actions の実行履歴を見る → success
ジョブは成功しているのに、コミットもファイルの移動も起きていない。
矛盾した状態に見えました。ワークフローのどこかが空振りしているのだろう、と考えました。
git fetch していなかっただけだった
実際には、その前日の午前中にちゃんと公開されていました。
記事も出ていたし、X の告知も自動で流れていました。
原因は git fetch していなかったことです。それだけです。
公開のコミットを作るのは GitHub Actions で、それはリモート側で起きます。
ローカルの作業ツリーは、こちらが取りに行くまで何も知りません。
# 誤り: ローカルの世界を見ている
git log --oneline -5
# 正しい: リモートの実際の状態を見る
git fetch origin
git log origin/main --oneline -5ls でフォルダを見るのも同じです。
自分が最後に同期した時点の世界を見せていただけでした。
「見た」つもりで、古い写真を見ていた
間違えた理由を振り返ると、確認したという感覚だけはあったことです。
ログも見たし、フォルダも見た。実行履歴も見た。3つも見ています。
でも3つのうち2つは、手元のコピーでした。
自動化したものが自分の手元の外で動いているとき、
手元をいくら見ても、外で起きたことは映りません。
古い写真を3枚見て「変化がない」と結論していたようなものでした。
残りの1つ、実行履歴のほうは外を見ています。
ただ、CI が「成功」を返しても、それはジョブが落ちなかったという意味でしかありません。
「意図した結果になった」は保証していない。
今回はたまたま結果も正しかったのですが、判定材料としては弱いままでした。
確認手段も外に置く
結局、一番確実なのは公開先そのものを見ることでした。
記事のページを開く。告知の投稿を見る。
数秒で終わりますし、手元の同期状態に左右されません。
自動化した対象が手元の外で動いているなら、確認手段も外に置く。
今は Zenn の記事ページを開くか、git fetch してからリモートのログを見るか、
どちらかにしています。
