Add: Gitea x OpenClaw 開発プロセス記事

2026-02-27 03:36:51 +00:00
parent 7bde88743e
commit f236ffd748
3 changed files with 123 additions and 4 deletions
@@ -0,0 +1,111 @@
+---
+sidebar_position: 2
+title: Gitea × OpenClaw 連携の開発プロセス実践ガイド
+description: Issue/PR Webhook連携でAI開発を回すための実運用プロセス（ブランチ戦略、レビュー、マージ、再発防止）
+hide_table_of_contents: false
+displayed_sidebar: null
+---
+
+# Gitea × OpenClaw 連携の開発プロセス実践ガイド
+
+## はじめに
+
+Gitea Webhook で OpenClaw を呼び出す構成は便利ですが、運用ルールが曖昧だとすぐ壊れます。
+
+この記事では、実際に運用しながら整えた **Issue/PR 駆動の開発プロセス** をまとめます。
+
+## 目的
+
+- Issue を起点に AI が修正提案・実装を進める
+- PR でレビューし、問題なければ main へ反映
+- ブランチ運用・反映手順を毎回明示し、Git に不慣れでも迷わない
+
+## 全体フロー
+
+1. Gitea で Issue を作成
+2. Webhook Bridge が OpenClaw にタスク転送
+3. 修正ブランチで実装・検証
+4. PR 作成
+5. PR Webhook で最終レビュー
+6. main へマージ
+7. Issue に進捗コメント（手順付き）
+
+## 運用ルール（重要）
+
+### 1) 変更は必ず作業ブランチで
+
+- `fix/issue-<番号>-<要約>`
+- `feat/issue-<番号>-<要約>`
+- `docs/issue-<番号>-<要約>`
+
+### 2) Issue コメントに毎回この3点を記載
+
+- ブランチ切替コマンド
+- 検証コマンド
+- main へのマージコマンド
+
+### 3) PR イベントも Webhook で処理
+
+`issues` だけでなく `pull_request` も受ける。
+対象アクションは最低限以下を推奨：
+
+- `opened`
+- `reopened`
+- `synchronize`
+
+## 実用テンプレ（そのまま使える）
+
+### ブランチ切替
+
+```bash
+git fetch origin
+git switch fix/issue-123-xxx
+# 古いgitなら: git checkout fix/issue-123-xxx
+```
+
+### 検証
+
+```bash
+python3 -m py_compile src/*.py app/*.py
+python3 app/web_ui.py --port 7860 --config config/config.yaml
+```
+
+### main へ反映
+
+```bash
+git switch main
+git pull origin main
+git merge --no-ff fix/issue-123-xxx
+git push origin main
+```
+
+## 破綻しやすいポイントと対策
+
+### Webhook が `EOF` で失敗
+
+- 原因の多くは受信サーバー側の例外落ち
+- `do_POST` 全体を `try/except` で囲み、必ず HTTP 応答を返す
+
+### 別機能の修正で Webhook が壊れる
+
+- ブリッジ機能を分離（例: Gitea用 / Discord用を別リポ・別サービス）
+- systemd サービスも分離
+
+### ローカル設定ファイルが pull を壊す
+
+- `config.yaml.example` を追跡
+- `config.yaml` は `.gitignore`
+
+## まとめ
+
+Gitea × OpenClaw 連携は、技術そのものより **運用ルールの明文化** が効きます。
+
+- ブランチ命名を固定
+- Issue コメントのテンプレを固定
+- PR Webhook まで含める
+- 失敗しやすい箇所を分離・自動化
+
+この4つを守るだけで、連携はかなり安定します。
+
+---
+*この記事は2026年2月時点の情報です。*