docs: align README and TODO with action flow
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# 簡介
|
||||
|
||||
這是一個 AI Code Review Action。Gitea Workflow 可以使用此 Action 讓 AI 助理根據不同面向分析 Push Request 中變更的內容後,將問題分級 Commnet 到 Push Request 中。
|
||||
這是一個 AI Code Review Action。Gitea Workflow 可以使用此 Action 讓 AI 助理根據不同面向分析 Pull Request 中變更的內容後,將問題分級 Comment 到 Pull Request 中。
|
||||
|
||||
# 流程(新 Push Request、新 Commit 觸發;若偵測到 AI 助理的自動提交則直接跳過)
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
# 設計
|
||||
|
||||
1. Gitea 的相關參數如果 inputs 沒有定義,則從 ${{ gitea.* }} 取得
|
||||
1. Gitea 相關參數中,`GITEA_TOKEN` 必須由 inputs 明確提供;`GITEA_SERVER_URL`、`GITEA_REPOSITORY`、`PR_NUMBER`、`PR_HEAD_BRANCH`、`PR_BASE_BRANCH` 等欄位若 inputs 沒有定義,則從 `${{ gitea.* }}` 取得
|
||||
2. BASE_URL 如果 inputs 沒有定義,則使用預設值
|
||||
3. Comment 加上些許 emoji 讓資訊有點活力
|
||||
4. 盡量將應用程式放在 ./app,修改 entrypoint.sh 與 Dockerfile 讓程式可以正常運行
|
||||
@@ -30,7 +30,7 @@
|
||||
# 使用說明
|
||||
|
||||
1. 在 Gitea 專案中建立 `.gitea/workflows` 資料夾
|
||||
2. 在 `.gitea/workflows` 資料夾中建立 `ai-review.yaml'
|
||||
2. 在 `.gitea/workflows` 資料夾中建立 `ai-review.yaml`
|
||||
3. 在 `ai-review.yaml` 中填入以下內容(選擇一個使用):
|
||||
|
||||
> **自動提交排除說明**:此 Action 會將自己的 commit message 標記為 `[ai-review-bot][success]` 或 `[ai-review-bot][failure]`,而且 action 執行時會先透過 Gitea API 檢查這次觸發的 PR head commit(優先用 `pull_request.head.sha`)是否含有這個 marker,若有就直接成功結束,避免 bot commit 造成重複觸發。若外層 workflow 也能先檢查一次,效果最好。
|
||||
@@ -180,7 +180,7 @@ jobs:
|
||||
issues: write
|
||||
```
|
||||
|
||||
### - Ollama
|
||||
### 6. Ollama
|
||||
|
||||
```yaml
|
||||
name: AI
|
||||
@@ -200,7 +200,7 @@ jobs:
|
||||
- name: AI Code Review
|
||||
uses: https://gitea.jsc.idv.tw/actions/code-review@${{ vars.ACTION_CODE_REVIEW_VERSION }}
|
||||
with:
|
||||
GITEA_TOKEN: ${{ secrets.RUNNER_TOKEN }}
|
||||
GITEA_TOKEN: ${{ secrets.RUNNER_TOKEN }}
|
||||
OLLAMA_BASE_URL: https://ollama.jsc.idv.me/v1
|
||||
OLLAMA_MODEL: ${{ vars.OLLAMA_MODEL }}
|
||||
permissions:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 階段一:基本流程串接
|
||||
- 目標:確保 action 可以被觸發,pipeline 各步驟依序執行,log 出每個主要階段的進入與完成。
|
||||
- 驗收:log 中能看到每個階段(如「Step1: pipeline start」、「Step2: findings merge」等)明確訊息,且流程能走完(即使還沒產生 findings)。
|
||||
- 驗收:log 中能看到每個階段(如「Step1: Pipeline 啟動」、「Step2: Findings 產生」、「Step3: Findings 合併」等)明確訊息,且流程能走完(即使還沒產生 findings)。
|
||||
- 已驗收:`code-review` job 的 log 已完整出現 `Step1` 到 `Step8`,並以 `Pipeline 完成` 結束。
|
||||
|
||||
## 階段二:Git Diff 排除 .gitea/ 資料夾
|
||||
@@ -15,9 +15,9 @@
|
||||
- 驗收:log 中能看到每個角色 findings 數量、合併後 findings 統計,並有「Step3: merged findings total=...」等訊息。
|
||||
- 已驗收:log 已顯示 5 個角色皆有分析結果,並出現 `Step3 merged findings total=13`。
|
||||
|
||||
## 階段四:AI 去重與角色確認
|
||||
- 目標:嘗試呼叫 LLM 進行 findings 去重與角色確認,API 額度不足時要有降級處理 log。
|
||||
- 驗收:log 中能看到 deduplication/resolution confirmation 成功或失敗(如 402),降級時有「保留所有問題」等明確訊息。
|
||||
## 階段四:AI 語意去重
|
||||
- 目標:嘗試呼叫 LLM 進行 findings 語意去重,API 額度不足時要有降級處理 log。
|
||||
- 驗收:log 中能看到 `AI 去重: N -> M 筆` 的成功訊息,或在失敗時出現 `AI 去重失敗(...),降級:保留所有問題` 之類的明確訊息。
|
||||
- 已驗收:log 已出現 `AI 去重: 13 -> 11 筆`,且程式具備失敗時保留所有問題的降級處理。
|
||||
|
||||
## 階段五:AI 排除問題過濾
|
||||
|
||||
Reference in New Issue
Block a user