note-articles/docs-tech/gitea-openclaw-dev-process/index.md

sidebar_position, title, description, hide_table_of_contents, displayed_sidebar

sidebar_position	title	description	hide_table_of_contents	displayed_sidebar
2	Gitea × OpenClaw 連携の開発プロセス実践ガイド	Issue/PR Webhook連携でAI開発を回すための実運用プロセス（ブランチ戦略、レビュー、マージ、再発防止）	false	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

実用テンプレ（そのまま使える）

ブランチ切替

git fetch origin
git switch fix/issue-123-xxx
# 古いgitなら: git checkout fix/issue-123-xxx

検証

python3 -m py_compile src/*.py app/*.py
python3 app/web_ui.py --port 7860 --config config/config.yaml

main へ反映

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月時点の情報です。