koide
f236ffd748
All checks were successful
Deploy Docusaurus Site / deploy (push) Successful in 28s
112 lines
2.9 KiB
Markdown
112 lines
2.9 KiB
Markdown
---
|
||
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月時点の情報です。*
|