Woodpeckerで軽量なCI/CDパイプラインを組み立てる

シンプルさをサーバーとAgentで読む

Woodpeckerはシンプルでありながら拡張性を持つCI/CDエンジンとREADMEに説明されています。リポジトリはGoで書かれ、デフォルトブランチはmainです。バッジにはパイプライン状態、カバレッジ、リリース、Docker、OpenSSFなどへのリンクがありますが、外部バッジは性能保証ではありません。

構成を読むときは、パイプラインを受け付けるサーバーと、実際にジョブを動かすAgentを分けます。READMEだけでは両者の配置や通信設定を詳しく確認できないため、導入先のネットワークと実行権限を先に整理します。

SQLiteとアイドル時の目安

READMEはデフォルトのデータベースとしてSQLiteを挙げています。アイドル時のメモリ使用量はサーバー約100MB、Agent約30MBと記載されています。これはREADMEにある静止時の目安であり、ジョブの並列数、リポジトリ規模、ログ量が増えたときの必要量を示す数値ではありません。

本番規模を決める前に、同時ジョブ数を固定した試験を行い、CPU、メモリ、ディスク、ログ保存量、SQLiteのロックやバックアップを記録します。インストールコマンドや設定例はREADMEに載っていないため、公式管理ドキュメントの版と実際の設定を照合します。

公開導入例はCodeberg

READMEが具体的な公開利用先として挙げるのはCodebergです。プライバシーと自由ソフトウェア開発に焦点を当てたGitホスティングで、Woodpeckerを主要なCI/CDエンジンとして使用していると説明されています。サーバー台数、パイプライン量、ハードウェアは記載されていません。

この例は導入可能性を知る手掛かりにはなりますが、自社の負荷を裏付けるベンチマークではありません。リポジトリの連携、コミットからの起動、成果物の保存、権限を小規模な検証リポジトリで再現し、失敗したジョブを再実行できることを確かめます。

プラグインを境界として管理する

Woodpeckerはプラグインで拡張でき、公式プラグインページにはコアチーム保守とコミュニティ保守の項目が並びます。READMEはプラグインの数、API版、設定例、配布形式、審査基準を示していません。プラグインがジョブ内でどの権限を持つかも、個別の文書確認が必要です。

採用時はプラグインを一つずつ導入し、コンテナや実行環境へのアクセス、入力シークレット、外部ネットワーク、生成物を確認します。CIの便利なステップとして登録する前に、同じ入力で再実行した結果と失敗時のログが予測できるかを確認します。

ドキュメントとコミュニティの入口

公式ドキュメントは`https://woodpecker-ci.org/docs/intro`にあり、管理者向けの一般的な導入ページもREADMEから参照できます。翻訳はWeblate、議論はMatrixスペース、資金支援はOpen CollectiveとGitHub Sponsorsへ案内されています。READMEは翻訳率やサポート応答時間を保証していません。

導入担当者は、実際に使った設定、サーバーとAgentのログ、ジョブ定義、プラグイン版を保存して問い合わせ材料にします。外部サービスのバッジや支援者表示を、運用サポート契約と混同しないことが必要です。

Apache-2.0と更新の見方

コードはApache-2.0、`docs/`以下はクリエイティブ・コモンズ 表示-継承 4.0 国際ライセンスとREADMEに記載されています。Apache-2.0の著作権・特許許諾や特許訴訟時の終了条件は、再配布形態を決める前にLICENSE全文で確認します。ライセンスは性能や安全性の保証ではありません。

向くのは、CIの実行環境とプラグインを自分で点検できるチームです。更新ではサーバー、Agent、パイプライン、SQLiteバックアップ、プラグインを同時に試します。まず一つのリポジトリで成功と失敗の両方を作り、Agent停止後の復帰と履歴参照を確認してから範囲を広げます。

小さなリポジトリでCIを通す

最初の検証対象は一つのリポジトリに限定し、コミット、成功ジョブ、意図的なテスト失敗、再実行を順に作ります。サーバーがジョブを受け付け、Agentが実行し、履歴とログが読めることを確認します。SQLiteの保存ファイルをバックアップし、再起動後に履歴が残るかも見ます。

プラグインを一つずつ登録し、シークレット、ネットワーク、成果物へのアクセスをログとコンテナ設定で確認します。Agentを一時停止して復帰させ、待機中ジョブの扱いを記録します。サーバー約100MB、Agent約30MBというアイドル時の記載を基準に、並列ジョブで増える資源量を測ってから配置を決めます。

ジョブ履歴を復旧まで追う

成功と失敗のジョブを作り、Agent停止後に待機中の処理と履歴がどうなるかを確認します。SQLiteのバックアップから戻した状態で同じリポジトリを再実行し、ログ、成果物、プラグイン版を照合します。

編集部の結論

自分でCI/CD基盤のサーバーとAgentを管理し、プラグインで処理を広げたいチームに向きます。READMEには大規模環境の性能値や詳細な構成例がないため、Codebergの導入実績だけで自環境へ当てはめることはできません。まず小さなリポジトリでジョブの待ち時間、Agentの実行、SQLiteの保存、失敗ログ、プラグイン権限を確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes