コメント
[?]bot確認
+---+ | 名 | +---+
名無し
ほげぼげ
+---+ | 名 | +---+
名無し
ほげぼげ
このブログCMSでは、Huskyのpre-commitとpre-pushを同じ検査の重複ではなく、速い確認と重い確認の二段階に分けている。記事、管理画面、認証、広告、デプロイ処理が一つのリポジトリにあるため、文言だけの変更でも型、構造テスト、秘密情報、AIレビューの状態まで影響し得るからだ。
*図: 速い失敗をコミット前に返し、リポジトリ全体の重い確認をpush前へ分離する。*
現在のフックは、古い記事にあったcorepack pnpm@11.1.1ではなく、どちらも単にpnpmを呼ぶ。リポジトリのpackageManagerはpnpm@11.6.0で、Nix dev シェルはCorepackを有効にする。したがって、フック内へ別のpnpmバージョンを直書きせず、リポジトリが宣言するバージョンを開発環境側で解決する構成である。
package.jsonにはprepare: huskyがある一方、.npmrcはignore-scripts=trueだ。新しいcloneでインストールしただけでフックが有効になったと決めつけず、チームで認めたセットアップ後にgit config core.hooksPathを確認する。
.husky/pre-commitの実行順は次のとおりだ。
set -eu
pnpm run format:check
pnpm run typecheck
pnpm run test
pnpm run secrets:staged
pnpm run clawpatch:precommitformat:checkはbiome check .、typecheckはtsc --noEmit、testはnode --test tests/*.test.mjsである。続いてGitleaksがステージ済み差分を--redact付きで検査し、最後にClawpatchの状態ゲートを通す。set -euなので、途中の終了コードが非0なら後続へ進まずコミットを止める。
ここには独立したpnpm run lintもpnpm run buildも入っていない。存在するスクリプトとフックで実際に呼ばれるスクリプトを混同しないことが、運用記事では重要になる。
.husky/pre-push自体は短い。
set -eu
pnpm run verify:push
pnpm run secrets:historyverify:pushは、Biome、TypeScript、Nodeテストに続き、管理機能の構造カバレッジ、広告スロットの静的監査、管理画面ルートのE2E、依存関係監査、Clawpatchのpushレビューを順番に実行する。最後にsecrets:historyがステージ済み差分だけでなくGit履歴をGitleaksで検査する。汎用的な「テスト一式」ではなく、このCMSで壊れやすい管理画面と広告配置までゲートに含めた点が実運用上の中心だ。
pnpmでは、オプションなしのpnpm auditがインストール済み依存の既知脆弱性を調べ、--prodは本番 dependenciesだけへ対象を狭める。このプロジェクトでは、ビルド、フック、テスト、デプロイに使うdevDependenciesも実行経路の一部なので、完了条件は次のコマンドが成功することとする。
pnpm audit確認時点のpackage.jsonでは、verify:pushが旧名のaudit:prodを呼ぶが、その実体はオプションなしのpnpm auditである。スクリプト名と実処理にずれは残るものの、実際のゲートは全依存を監査する。完了判定ではスクリプト名から対象範囲を推測せず、定義と監査結果の両方を確認する。名前と実処理の差を隠さないことも品質ゲートの一部である。
clawpatch:precommitはnode scripts/clawpatch-gate.mjs statusを実行する。ラッパーはclawpatch status --jsonを解析し、openFindingsまたはactiveLocksが1件でもあれば失敗する。件数が0なら通過するだけで、修正、コミット、pushを自動では行わない。
push側のclawpatch:pushは、先に次を実行してから同じ状態判定を行う。
clawpatch ci --include-dirty --limit 3 --jobs 3 --jsonこれにより未コミットの作業ツリーもレビュー入力へ含め、同時実行数などを明示的に制限する。過去のopenFindings=0を記事へ固定値として書かず、そのpush時点のJSONを毎回判定するのが正しい。
Git フックは早いフィードバックには有効だが、--no-verifyやフック未設定の環境では走らない。保護すべきブランチでは同等のサーバー側CIも用意し、ローカルフック通過を本番動作確認と同一視しない。また、現行verify:pushにはbuildが含まれないため、リリース前はREADMEの方針どおりpnpm build && pnpm run verify:pushを別途完走させる。