Gitの警告を失敗扱いして、自動バックアップを飛ばしていました

毎朝のまとめを、GitHubにも自動で保存するようにしていました。一通り動かしてみると、朝の通知は届くのに、バックアップが保存されていませんでした。

調べると、変更を記録する道具「Git」が出した注意書きで、保存の手順が止まっていました。

注意書きを、失敗だと思っていた

きっかけになったのは、このメッセージです。

warning: LF will be replaced by CRLF

「改行の書き方を変換します」という注意書きです。このとき、Gitの操作自体は失敗していませんでした。でも、その操作を呼び出す側が「失敗した」と受け取ってしまいました。

使っていたのはWindows PowerShell 5.1です。決めた手順をまとめて実行する道具で、「エラーがあったら止める」という設定（$ErrorActionPreference = 'Stop'）にしていました。

この環境では、Gitの注意書きも止まるきっかけになっていました。しかも、失敗したときは「保存は飛ばして、まとめの通知は続ける」という手順にしていました。

Gitが注意書きを出す

改行の書き方を変換する、というお知らせだった。

失敗したと読み違える

保存をやめて、失敗したとき用の手順へ進む。

通知は続く

保存だけ飛ばされ、見える通知はいつもどおり届く。

「通知は届けたい」という処理が、保存の失敗を見えにくくしていました。

最初は、注意書きを画面に出さないようにしました。それでも止まります。表示を消しても、「失敗した」と受け取るところは変わっていませんでした。

ただし、同じPowerShellでもバージョンによって違います。Microsoftによると、7.2以降は外部コマンドのエラー出力を別へ流した場合の扱いが変わっています。PowerShell公式の設定変数の説明

同じスクリプトを調べるときも、まず動いているバージョンを確認します。

修正したのは2点です。

番号の意味は、操作によって違います。「変更があるかを調べる」と「GitHubに送る」では、同じ番号でも同じ意味とは限りません。それぞれの結果を確かめるようにしました。

失敗したときも、「パソコンには記録できたが、GitHubには送れなかった」のように、どこまで終わったかを残します。

直したあと、もう一度動かしました。朝のまとめができ、パソコンにもGitHubにも同じ内容が残っている。そこまで見て、直ったと判断しました。コードを読むだけでは見つからなかった不具合です。

今なら同じ自動化を確認するとき、成功通知だけでなく、途中で飛ばされた工程がないかも見ます。最後まで走ったことを、全部成功したことの代わりにしないためです。