「スキップ印」がpush全体を無かったことにする
コミットメッセージに1つ印を入れただけで、そのpushに含まれる変更がまるごと本番に出ない。エラーも出ません。実測で挙動を確定させた話です。
静的サイトを Git 連携で自動デプロイしていると、コミットメッセージに特定の印（角括弧つきのスキップ指示）を入れることで、そのコミットのビルドを飛ばせます。ドキュメントだけ直したときにビルドを走らせない、という節約のための機能です。
この印で事故が起きました。印を付けたドキュメントのコミットを、出力が変わるコミットと同じpushに混ぜたところ、push全体がスキップされました。ドキュメントのコミットだけが飛ぶのではありません。同じpushに入っていた、サイトの表示を変えるコミットも道連れになります。
いちばん悪いのは、エラーが出ないこと
ビルドが失敗したのなら気づけます。通知が来ますし、ダッシュボードが赤くなります。ところがスキップは成功でも失敗でもなく「実行しなかった」という結果なので、何も起きません。pushは通り、コミットはリポジトリに載り、見た目には作業が完了しています。本番だけが古いまま残ります。
気づくのは、あとで本番を見に行ったときです。「直したはずの箇所が直っていない」と思って、コードを疑い、キャッシュを疑い、最後にデプロイの履歴を見て、そこで初めて分かります。
印がpushの何番目にあるかは無関係だった
最初は「先頭のコミットで判定しているのだろう」と考えました。それなら印つきコミットを途中に挟めば安全なはずです。しかし実測したところ、印がpushの何番目にあっても、pushはまるごと飛びました。順序を工夫して回避する、という方針は成立しませんでした。
ところが、プラットフォームによって判定が違った
後日、別のホスティング方式を使っているサイトで同じ状況が起きたときは、挙動が違いました。そちらはpushの先頭コミットだけを見て判定しており、印つきコミットが途中に混ざっていても、他のコミットは通常どおりビルドされたのです。
同じ事業者のサービスでも、静的サイト向けの仕組みと、より新しいアセット配信の仕組みとで判定が違いました。両方を並行して使っている場合、片方で通用した経験がもう片方で通用しません。これは調べて分かったことではなく、両方で同じ操作をして結果を比べて分かったことです。
運用をどちらか一方に寄せる
判定が違うと分かった時点で、迷わないほうに揃えました。印つきのコミットを、出力が変わるpushに混ぜない。ドキュメントだけを直したときは、印をつけて単独でpushする。この2つを守れば、どちらの仕組みでも同じ結果になります。
- 出力が変わるpushには、印つきコミットを1つも入れない
- ドキュメントだけの変更は、印をつけて単独でpushする（ビルドが走らないので枠を消費しない）
- 迷ったら印をつけない。ビルドが1回走るだけで、事故は起きない
- 印について文章で説明するときは、コミットメッセージの本文に印の実物を書かない（そのコミット自体が飛ぶ）
最後の項目は笑い話のようですが、実際に踏みかけました。「印を混ぜないこと」という注意書きをコミットメッセージに書こうとして、その中に印の実物が入っていたのです。
そもそもの背景: ビルド回数には上限がある
この印を使いたくなる理由は、無料枠のビルド回数に上限があるからです。しかも上限はアカウント単位で、複数のサイトが同じ枠を分け合います。上限に達すると、その月は全サイトのビルドが止まります。
消費されるのはコミット数ではなくpush回数です。したがって、こまめにコミットして最後に1回pushすれば、枠の消費は1回で済みます。印に頼るより、pushをまとめるほうが効きます。
確認のために本番へpushしない、というのも同じ理由です。ビルド後の出力ファイルを手元で検査すれば、枠を使わずに確かめられます。
枠を1回も無駄にしないための小細工
関連して、初回ビルドが失敗して枠を1回捨てる、という事故も潰しました。ホスティング側の既定の実行環境が古く、使っているフレームワークの要求バージョンを満たしていなかったためです。リポジトリにバージョン指定のファイルを1つ置くだけで解決します。
設定を管理画面ではなくリポジトリに置いたのは意図的です。画面側の設定は、次に触る人から見えません。ファイルとして置いてあれば、リポジトリを開いた時点で目に入ります。
この記事の元
この記事は、「沖縄移住データブック」と「おきなわ防災てびき」の運用で実際にやったことから書き起こしています。 方針そのものは運営方針にまとめています。