Gitフックとnqで作る最小CI

 (mccd.space)
1 ポイント 投稿者 GN⁺ 9 시간 전 | 1件のコメント | WhatsAppで共有
  • 個人サーバーの bare Git リポジトリに post-receive フックを追加し、テスト、ビルド、ファイル移動を自動化するシンプルな CI 構成
  • 既存の CI は複雑な YAML 設定、遅い実行、難しいセルフホスティングがある一方で、完全なビルド分離やシークレット管理までは必要なかった
  • フックで処理を直接実行すると、失敗時に push が拒否されたり完了が遅れたりするため、最小ジョブキュー nq でバックグラウンド処理する
  • フックは nq だけを呼び出し、ログは ssh server nqtail -a で確認できるため、素早くシンプルに運用できる
  • 必要に応じて landdown・Podman でビルドを分離し、sops でシークレットを管理したり、Git のメールパッチ・git-shell・git http-backend で開発方式を拡張できる

post-receive フックと nq の構成

  • 個人サーバーで ssh server git init --bare repo によりリポジトリを作成し、git clone server:repo で複製する
  • bare リポジトリの hooks ディレクトリにシェルスクリプト形式の post-receive フックを置き、push のたびに CI を開始する
  • 処理をフックで直接実行すると、2 つの問題が起きる
    • スクリプトが失敗した場合、push が拒否される
    • スクリプトの実行が遅いと、push の完了も一緒に遅れる
  • フックでは最小ジョブキュー nq を呼び出し、処理を バックグラウンドキュー に追加する
    • ログは ssh server nqtail -a で確認する
    • 設定手順は短い チュートリアルで確認できる

分離と開発方式の拡張

  • ビルドをサンドボックスで実行するには landdown を使える
  • Podman でビルドをホスト環境から分離したり、sops でシークレットを管理できる
  • bazaar 型の開発には、メールで Git パッチを受け取る構成が適している
  • cathedral 型の開発は git-shell または git http-backend で構成できる

関連記事

1件のコメント

 
GN⁺ 9 시간 전
Lobste.rs の意見

  • CI には少なくとも 2 つの問題がある
    簡単な問題はコード変更時に make test を実行することで、難しい問題は Linux、Windows、Mac のすべてで make test を実行すること

    • Linux は簡単で Windows は難しいが、macOS は苦痛なレベル
    • CI で難しい部分は、失敗時のデバッグまで支援する ジョブ実行エンジン だと思う
      既存エンジンの開発者体験とデバッグ機能がいつも後回しなのが不満で、https://ci.pico.sh で CI システムを作っている。DSL も嫌いだし、階層的につながる YAML はじわじわと生命力を吸い取られる感じがする
    • この方式は簡単な問題を解決しており、QEMU で BSD 系をサポートし、Docker で複数のディストリビューションまで拡張できるかもしれないが、それ以上には より完全なツール が必要に見える

  • これを gitolite 上に構築し、Temporal に渡してビルド工程を制限なく制御したことがある
    実行失敗時に push を拒否することもできるが、通常はフックを通した後で失敗を別途処理しており、構成も単純で楽しかった

    • gitolite の アクセス制御ツール が特に気に入っていて、存在しないリポジトリに push して新しいリポジトリを作れる方式も素晴らしい

  • シェルスクリプト実行を中心にしたもう 1 つの最小 CI として laminar CI があり、Web UI も提供している

  • ずっと前、Windows 専用の企業環境で、チーム全体が使う ローカル CI サーバー として Mac mini を置いて iOS アプリをビルドしており、初期に試した Git 活用法の 1 つだった

  • https://mccd.space/git/ で見つけたが、stagit の fork を使っているようだ
    数か月前まで Forgejo と Woodpecker を運用していたが、不要な機能が大半だったので両方とも削除し、これに似た より軽い構成 を探していた。次の課題が CI だったのでタイミングが良く、近く公開する小さなライブラリを SourceHut にミラーするか考えている

    • stagit を fork して連絡先メールとナビゲーションバーを追加し、CSS 変更用の ID を入れ、不要な情報は削除した
      リポジトリは git-daemon で Web に読み取り専用公開しており、全体の構成方法は ここ にまとめてある

  • この投稿で nq を初めて知ったが、おそらく systemd-run を使うと思う
    ほぼすべてのランナーで Nix を使っているので、nix flake check の結果を OTLP メトリクスとログとして公開すれば、CI 要件を監視システムで解決できそうだ

  • このようなシンプルなセルフホスト開発プラットフォーム構成は気に入っている
    CI 用には、軽量でシンプルなコンテナシステムである bubblewrap を簡単に設定して使える。ただ、nq を使うと CI 失敗時の push 拒否 はできないように見えるが、どう処理しているのか気になる

    • スクリプトを制限するために Landlock を使う 補助ツール もあり、使い方はもう少し簡単だと思う
      さらに分離が必要なら Podman、Docker、bubblewrap を追加できる。テストを実行する pre-commit フックを置かないのと同じ理由で、CI 失敗時に push を拒否していない。壊れた作業でもコミットや push が必要なときがあり、push が非常に遅くなることもあるためだ。拒否が必要なら nq なしで CI を同期実行し、終了コードが 0 でないときに push を止めればよい
      あるいは main 以外のブランチ は nq で実行し、main ブランチだけ同期実行することもできる

  • landdown リンク が壊れているようだ