CI/CD

情境

你的團隊把多個微服務收進一個 monorepo（services/api、services/worker、web）。你不想每次 push 都重審整個 repo（燒 token），也不想讓一個 web 的改動觸發對 services 的評審。你要在 GitLab CI 上做到「只審本次 MR 實際碰到的目錄」。

Step 1 — 在 pipeline 裡算出「變更的頂層目錄」

git diff --name-only "origin/$CI_DEFAULT_BRANCH"...HEAD \
  | cut -d/ -f1 | sort -u | paste -sd, -

例如輸出 services/api,web——只有這兩個子樹真的變了。

Step 2 — 用變更目錄當 scan path 跑評審

CHANGED="$(git diff --name-only origin/main...HEAD | cut -d/ -f1 | sort -u | paste -sd, -)"
ocr scan --path "$CHANGED" \
  --background "MR: $CI_MR_TITLE" \
  --format json --audience agent > review.json
cat review.json | jq -e '.status == "success"'

用 ocr scan --path 而非 ocr review 的 --from/--to——因為 monorepo 的 merge-base 常常被其他子樹的推送污染，--path 讓我們精準限定審查範圍，只對「真的變了的目錄」整檔審。

Step 3 — 貼成 GitLab Discussion

python3 - <<'PY'
import json, os
mr = os.environ["CI_MR_IID"]
data = json.load(open("review.json"))
for c in data.get("comments", []):
    # 對每個 comment 在 MR 對應檔案的行上建立 discussion
    ...  # 用 GitLab notes API POST /projects/:id/merge_requests/:iid/discussions
PY

Step 4 — 避免重複審：檢查 MR notes 是否已含 OCR 產物

curl -s --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \
  "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MR_IID/notes" \
  | jq '[.[] | select(.body | contains("OpenCodeReview"))] | length'

大於 0 就 exit 0 跳過——省下重複的 LLM token（官方建議的「僅在建立時」替代方案）。

為什麼選這條審查路徑

monorepo 最怕「評審範圍失焦」。ocr scan --path <變更目錄> 比 range diff 更穩：不受 merge-base 漂移影響、天然限定在「這顆 MR 的責任範圍」、且對目錄內整檔審（重構搬移也能抓到）。加上「MR 已審過就跳過」的防重複邏輯，token 成本從「每次 push 全審」降到「每個 MR 只審一次、且只審受影響子樹」。

預期產出

CHANGED = services/api,web
ocr scan: 2 subtrees, 11 files reviewed, 5 comments posted
No duplicate review: next MR push skipped (note already exists)

情境

公司有 20+ 個 repo 要接 OCR，但每個 repo 的 workflow 都是複製貼上、設定各自漂移。你要建立統一評審閘道：一個可重用 workflow template（含門檻、報告、失敗處理），全部 repo 只改一行引用就接入。

Step 1 — 建立可重用的 composite action（GitHub）

# .github/actions/ocr-gate/action.yml
runs:
  using: composite
  steps:
    - run: |
        npm install -g @alibaba-group/open-code-review@${{ inputs.version }}
        ocr review \
          --from "origin/${{ github.base_ref }}" \
          --to "origin/${{ github.head_ref }}" \
          --background "${{ github.event.pull_request.title }}" \
          --format json --audience agent > ocr-report.json
      env:
        OCR_LLM_URL: ${{ secrets.OCR_LLM_URL }}
        OCR_LLM_AUTH_TOKEN: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
        OCR_LLM_MODEL: ${{ inputs.model }}
    - run: |
        # 門檻: high-severity 評論 > 0 就讓 PR 卡住（blocking gate）
        python3 ocr-gate.py ocr-report.json

Step 2 — 每個 repo 只引用它（一行的接入成本）

# 各 repo 的 ocr-review.yml
jobs:
  ocr-gate:
    runs-on: ubuntu-latest
    permissions: { contents: read, pull-requests: write }
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # 淺克隆會壞 merge-base
      - uses: your-org/ocr-gate/.github/actions/ocr-gate@v1
        with: { model: claude-opus-4-6 }

Step 3 — 閘道腳本：把「綠燈」的定義寫對

# ocr-gate.py 的核心判斷（別只看 exit code）
data = json.load(open("ocr-report.json"))
assert data["status"] == "success", "OCR failed"
assert data["summary"]["files_reviewed"] > 0, "Zero files reviewed — check scope"
blocking = [c for c in data["comments"] if c.get("severity") in ("high", "critical")]
if blocking:
    print("BLOCKED:", len(blocking), "high/critical findings")
    sys.exit(1)  # PR 卡住

Step 4 — 上送報告與指標

# 把 ocr-report.json 存成 artifact + 送 telemetry（統一監控）
OCR_ENABLE_TELEMETRY: "1"
OTEL_EXPORTER_OTLP_ENDPOINT: collector:4317
OTEL_SERVICE_NAME: ocr-gate

為什麼選這條路徑

「統一閘道」的價值是把規則收斂到一處：門檻邏輯、secret 命名、報告格式都只定義一次。每個 repo 的接入成本降到「複製 6 行」——導入阻力最小化。真正的關鍵是把「綠燈」定義寫對（Step 3）：不檢查 files_reviewed > 0 的話，「全檔被過濾」也會綠燈——那就是「空審查通過」的假陽性。

預期產出

Template v1 上線 → 20 repo 一週內全接
閘道統計: 每月擋下 40+ 顆含 high-severity 的 PR
假陽性檢查: 零「空審查通過」事件（files_reviewed=0 時確實卡住）