dotfiles にも CI を — 破壊的インストーラの冪等性を Ubuntu と Kali の二役で検証する

Sat, 04 Jul 2026 10:00:00 +0900

自分の開発環境が、ある日再現できなくなる

開発環境を1本のスクリプトにまとめている。シェル設定・プロンプト・ターミナルマルチプレクサ・言語ランタイム・クラウドCLIを、./setup_env.sh 一発で入れる。最終的に 1,358 行になった。新しいマシンでも、OS を入れ直した後でも、同じ環境がすぐ戻ってくる。便利だ。

便利なのだが、ひとつ不安が残った。今度は そのスクリプト自体が壊れたときに気づけない。うっかり片方の OS でしか通らない書き方をしても、次にそのマシンを触るまで分からない。設定ファイルを追記する処理が既存の .zshrc を壊しても、実際に事故ってから気づく。手作業をスクリプトにまとめた結果、こんどはその 1 本のスクリプトに、環境の再現を丸ごと預けることになった。

それで、dotfiles にも CI をつけた。やることは本番インフラの検証と変わらない。「危険な変更が入ったら、その場で赤くする」 を、開発環境の構築スクリプトに対してやる。この記事では、その CI（GitHub Actions）を抜粋して紹介する。リポジトリ固有の名前やレイアウト名は伏せるか一般化し、コードは要点を示す抜粋にしてある。

数字で見た中身

実環境の中身は出せないので、代わりに構成の規模で示す。以下はこの dotfiles と CI を実測した値だ。

指標	値
`setup_env.sh` 行数（単一エントリポイント）	1,358
CI ジョブ（builder / breaker / aggregate）	3
検証環境（Ubuntu runner / Kali コンテナ）	2
`scripts/ci/validate_*` チェッカ	14
CI で生成検証する Zellij レイアウト（総数9本のうち）	8
インストーラ検証の段階（dry-run → 実行 → `--clean` 再構築）	3

全体構成

 push / PR / dispatch
 │
 ┌────────────────┴────────────────┐
 ▼ ▼
 ┌──────────────────────┐ ┌──────────────────────────┐
 │ builder (Ubuntu) │ │ breaker (Kali container) │
 │ shellcheck / clippy │ │ shellcheck / clippy │
 │ setup --dry-run │ │ setup --dry-run │
 │ 隔離HOMEで実インストール │ │ 隔離HOMEで実インストール │
 │ --clean で再構築 │ │ --clean で再構築 │
 │ layout ×4 を assert │ │ layout ×4 を assert │
 └──────────┬───────────┘ └────────────┬─────────────┘
 │ report (artifact) │ report (artifact)
 └────────────────┬──────────────────┘
 ▼
 ┌──────────────────────┐
 │ aggregate │
 │ 2環境のレポートを統合 │
 │ → CI step summary │
 └──────────────────────┘

CI は 3 ジョブに分けている。同じインストーラを 2 つの OS で流す builder と breaker、そして両者のレポートを 1 枚にまとめる aggregate だ。

「秘密が漏れない」を Lean で証明して CI ゲートにした Rust CLI のリリースパイプライン

Mon, 15 Jun 2026 12:00:00 +0900

「テストが緑」で満足できなかった理由

エージェントに本物の API キーを渡さずに動かす CLI ツールを開発している。守りたい性質はシンプルで、子プロセスに本物の鍵を渡さないこと。ここが崩れれば、このツールを使う意味はない。

ただ、テストが通っているだけでは確認として物足りなかった。テストが言えるのは「この入力では問題ない」までで、「どんな入力でも問題ない」ではない。鍵を扱う以上、その差は無視できない。

そこで Lean で証明を書き、CI でビルドするようにした。手間はかかるが、扱うものを考えれば妥当な投資だと思う。この記事では、そのときに組んだ CI/CD を抜粋して紹介する。プロジェクト固有の内部名は伏せ、設計と仕組みのところだけを残した。

数字で見た中身

指標	値
Lean の定理／補題（`formal/lean`）	28
Lean 証明中の `sorry` / `axiom`	0
安全不変条件ゲート（CI ステップ）	11
リリース配布ターゲット（matrix）	5
サプライチェーン検査	cargo-deny + Trivy

地味だが効いているのが、sorry（証明の穴埋めサボり）と axiom（無証明の仮定）が両方とも 0 という点だ。核の不変条件を仮定でごまかさず最後まで証明している、ということで、これが CI を緑にする条件に入っている。

CI は三層に分けている

┌─────────────────────────────────────────────┐
│ 1. 形式検証（核） │
│ 「子プロセスは本物の鍵を受け取らない」を │
│ Lean で証明 — 定理28 / sorry・axiom 0 │
├─────────────────────────────────────────────┤
│ 2. 安全不変条件ゲート × 11 │
│ deny-before-inject / DNS guard / │
│ audit boundary / secret-type … を │
│ 1条件＝1ゲートで機械チェック │
├─────────────────────────────────────────────┤
│ 3. 汎用品質 + サプライチェーン │
│ fmt / clippy -D warnings / test / │
│ cargo-deny（advisories, bans, sources） │
└─────────────────────────────────────────────┘

1. 核は Lean で証明して、CI でビルドする

「子プロセスは本物の鍵を受け取らない」という核の性質は、formal/lean に証明として置いている。定理と補題で28本、うち sorry も axiom も無し。CI は毎回この証明をビルドして、サボりや無証明の仮定なしで通ることを確かめる。

Supply-Chain on 万屋猫Labs

dotfiles にも CI を — 破壊的インストーラの冪等性を Ubuntu と Kali の二役で検証する

自分の開発環境が、ある日再現できなくなる

数字で見た中身

全体構成

「秘密が漏れない」を Lean で証明して CI ゲートにした Rust CLI のリリースパイプライン

「テストが緑」で満足できなかった理由

数字で見た中身

CI は三層に分けている

1. 核は Lean で証明して、CI でビルドする