k8up: やめたアプリの残り(noren・shadai)を通知の見張りから外す

[5ym]

何が起きていたか

k8up の日次通知が 6 件の FAILED を出していた: noren 3 本(154 時間前)と shadai 3 本(72 時間前)。noren は 09-12 に namespace ごと撤去、shadai は 09-16 に todoroku へ改名したもので、通知は過去 8 日に出てきた (host, path) を「あるべきもの」とみなすため、窓が閉じるまで鳴り続ける。

何をしたか

• repo 側(実施済み、2026-09-19 01:50 UTC): noren のスナップショット 5 本を restic forget(消してよいとの指示)。shadai の 12 本は改名前の履歴として残し、restic tag --add retired を付けた。Job は k8up namespace で 1 回流し、1 時間で消える
• notify.js: retired タグの付いたスナップショットを数えない
• README: 「やめたアプリの残り」に 2 つのやめ方と Job の打ち方。取っているものの表から noren を外し todoroku に

確認

次の 18:00 UTC の通知で OK になるはず。マージ後に kubectl create job --from=cronjob/k8up-notify で先に確かめる。

🤖 Generated with Claude Code

https://claude.ai/code/session_01JgGYf5qbjDXYhtzcpLsGvv

[claude]

Claude finished @5ym's task in 2m 52s —— View job

---

レビュー完了

タスクリスト

• コンテキスト収集 (diff、notify.yaml/notify.js、README、schedules.yaml)
• 不具合・境界値の確認
• セキュリティ確認
• 設計・一貫性の確認
• テスト観点の確認
• レビューコメント投稿

全体所感

小さく、動機と手順が README・コード両方にきちんと書かれていて追いやすい変更です。ロジックは狙いどおりに実装されています。

notify.yaml (notify.js)

• if ((s.tags ?? []).includes("retired")) continue; は latest を構築するループの先頭に正しく置かれており、retired タグ付きスナップショットを stale/empty/superseded などすべての判定から一貫して除外できています。tags が undefined/null のケースも ?? [] でカバー済みです。
• tags はこの追加以外でこのスクリプト内に依存箇所が無いことを確認したので、既存ロジック(silent の Schedule ベースの判定など)との衝突はありません。
• noren は restic forget で完全削除、shadai は retired タグで履歴を残しつつ通知から除外、という 2 通りの使い分けは PR 本文の説明と一致していて理にかなっています。

README

• 新設した「やめたアプリの残り(2026-09-19)」節は、既存の「確かめたこと(2026-09-07)」等と同じ見出し規約(日付入り ##)に沿っています。
• 表の noren → todoroku の書き換えは schedules.yaml(280〜288 行目、namespace todoroku)の実態と一致しており、正しい追従です。

軽微な指摘(要確認・ブロッカーではありません)

• インラインコメントの通り、README 166〜168 行目の runbook スクリプトは -ec で動くため、restic forget(166 行目)が失敗すると restic tag --host shadai --add retired(167 行目)が実行されずに止まります。noren の forget と shadai の tag は本来独立した操作なので、今後このテンプレを使い回す際に気づきにくい失敗モードになり得ます。今回は実行ログで成功済みとのことなので実害はありません。

テスト

• notify.js はこのリポジトリの他の箇所同様、自動テストが無い運用です(既存コードの慣習と一致)。PR 本文にある「次の 18:00 UTC の通知」および kubectl create job --from=cronjob/k8up-notify での事前確認が実質的な検証手段になっており、インフラ変更としては妥当な確認方法だと思います。

セキュリティ

• 新しいシークレットや権限の追加は無く、既存の k8up-global を使い回しているだけなので懸念はありません。

[claude]

要確認(軽微): -ec で動くスクリプトなので、166 行目の restic forget が失敗する(該当スナップショットが無く $() が空になり、restic が「ID もポリシーも無い」で落ちる、など)と 167 行目の restic tag --host shadai --add retired は実行されずスクリプトが終わります。noren の forget と shadai の tag は独立した操作なので、片方の失敗がもう片方を止めてしまう作りになっています。今回はログで成功を確認済みとのことなので実害は無いはずですが、このコマンド列をテンプレとして今後使い回す際に気づきにくい失敗モードだと思うので、|| true や 2 つの Job に分けるなどの余地があるかもしれません。ブロッカーではありません。

[claude]

Claude finished @5ym's task in 1m 30s —— View job

---

レビュー完了

タスクリスト

• コンテキスト収集(差分、notify.yaml、README、schedules.yaml)
• 前回レビュー以降の変更点確認(f04e4c7)
• 不具合・境界値の確認
• セキュリティ確認
• 設計・一貫性の確認
• テスト観点の確認
• レビューコメント投稿

全体所感

追加コミット f04e4c7 は前回の指摘(-ec スクリプトで restic forget が失敗すると restic tag が実行されない件)にきちんと対応しています。

apps/k8up/README.md(runbook スクリプト)

• ids=$(restic snapshots --host noren --compact | awk ...) で ID を変数に取り出し、[ -n "$ids" ] && restic forget $ids で「消す対象が無ければ forget 自体をスキップ」する形に変更されています。sh -ec の下では AND-OR リストの最後ではないコマンド([ -n "$ids" ])の失敗は set -e の対象外になるため、2 回目の実行などで noren のスナップショットが既に無い場合でも、スクリプトは途中で落ちずに restic tag --host shadai --add retired まで進みます。狙いどおりに動く実装です。
• 追加されたコメント(「2 つの操作は独立。消すものが無くても(2 回目など)tag のほうまで進む」)も実装と一致しています。
• 細かい点(要確認・ブロッカーではありません): restic forget $ids 自体(AND-OR リストの最後のコマンド)が何らかの理由で失敗した場合は、これまでどおり set -e により後続の restic tag は実行されません。ただし、これは前回指摘の「スナップショットが無いだけで落ちる」という具体的な不具合とは別物で、実行時エラーが起きたら止まるのはこの手の運用スクリプトとしては妥当な挙動とも言えるので、対応不要と考えます。

notify.yaml

• 前回から論理的な変更は無く、コメントの追加のみです。retired タグを持つスナップショットを除外するロジックは既にレビュー済みで問題ありません。

README の表・見出し

• noren → todoroku の書き換えは schedules.yaml(287〜288 行目、namespace todoroku)と一致しています。

セキュリティ

• 新しいシークレットや権限の追加は無く、既存の k8up-global を使い回しているだけです。懸念はありません。

テスト

• notify.js は自動テスト無しの既存運用と一致。README の runbook はインフラ変更で、PR 本文にある通り次の通知や kubectl create job --from=cronjob/k8up-notify での事前確認が実質的な検証手段になっており、妥当です。

以上、追加対応で前回の指摘は解消されており、他に問題は見つかりませんでした。