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 だ。

Zellij on 万屋猫Labs

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

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

数字で見た中身

全体構成