AI 程式設計教學中文版
官方教學中文版整合與自動化

GitHub Action

run-gemini-cli GitHub Action:在儲存庫裡接入 Gemini CLI,支援 PR review、issue triage、按評論觸發和定時任務。

📖 本篇術語速查表
英文 / 縮寫中文一句話解釋
GitHub Action在流水線裡跑 Gemini CLI。
觸發triggerAction 在什麼事件執行。
許可權permissions給 Action 的最小許可權。

不想讀完?把下面這段提示詞丟給 AI 幫你跑完——幫你配一個跑 Gemini CLI 的 GitHub Action。

你是 Gemini CLI GitHub Action 顧問。

【角色】
Gemini CLI GitHub Action 顧問,按最小夠用、安全合規優先的原則給可落地方案,每條結論都落到能照做的步驟或示例,不停留在空泛建議。

【輸入】
- 想在 CI 裡做什麼:___
- 觸發時機:___
- 讀還是寫儲存庫:___
- 輸出去向:___
- 經驗水平:___

【工作流程】
1. 判斷適不適合放 Action
2. 設計觸發和憑據存放
3. 按最小給許可權
4. 給穩妥落地順序
5. 給驗證

【輸出規範】
▌一、是否適合 Action
▌二、觸發 + 憑據存放
▌三、最小許可權
▌四、落地順序 + 驗證

【硬約束】
- 先只讀試跑,寫許可權謹慎放
- token 最小必要,憑據走 secret
- 失敗有清晰反饋
- 不要替我臆測情況或編造不存在的設定,資訊不全先問清
- 不確定的設定或介面一律以官方文件為準,禁止照搬過時寫法

google-github-actions/run-gemini-cli 把 Gemini CLI 放進 GitHub Actions。它適合做 PR review、issue triage、程式碼分析、修復建議和儲存庫自動化。

GitHub Action 預設應該只讀。涉及 label、comment、push、PR 修改或釋出時,必須收緊 permissions、事件觸發和身份條件。

能做什麼

  • 自動審查 pull request。
  • 自動標註和分流 issue。
  • 在 issue 或 PR 評論裡透過 @gemini-cli 觸發。
  • 在 schedule 任務裡做週期性檢查。
  • 呼叫 gh 等 CLI 與 GitHub 互動。

快速接入

官方推薦先把 API key 放到 GitHub secret:

GEMINI_API_KEY

然後在本地 Gemini CLI 中執行:

/setup-github

也可以手動複製官方 examples/workflows 到儲存庫的 .github/workflows

常見工作流

Gemini Dispatch       統一分發評論觸發的請求
Issue Triage          自動分流 issue
Pull Request Review   自動或手動審查 PR
Gemini CLI Assistant  在 issue/PR 評論裡處理請求

安全設定

接入 CI 時重點檢查:

  • secret 不寫入儲存庫。
  • checkout 步驟按需關閉憑據持久化。
  • 工作流許可權最小化。
  • 對 fork PR 保持保守。
  • 明確哪些評論命令允許觸發寫操作。

設計原則

GitHub Action 裡的 Gemini CLI 應該預設只讀。PR review、issue triage、release notes 草稿這類任務可以先只生成評論或摘要;需要寫 label、開 PR、push commit 的任務必須用更嚴格的 workflow permission 和觸發條件。

對 fork PR 尤其要保守:不要把高許可權 secret 暴露給不可信程式碼路徑,不要在未審查 diff 的情況下執行儲存庫指令碼。能用 pull_request 只讀事件解決的,不要直接上 pull_request_target

場景推薦許可權
PR review 草稿read-only + comment 限制
Issue triage labelissues write,但限制觸發條件
維護者評論觸發校驗 actor / association
Fork PR不暴露高許可權 secret
自動修復 PR獨立 workflow 和人工審批

接入路徑

推薦先在本地 Gemini CLI 裡跑 /setup-github 生成樣板,再人工審查 workflow。不要直接複製網上片段進生產儲存庫。審查重點是:

  • permissions 是否最小。
  • checkout 是否持久化憑據。
  • prompt 是否會讀取敏感檔案。
  • 是否限制評論觸發者身份。
  • 是否把結果作為建議,而不是直接合並修改。

驗收方式

用測試儲存庫跑三條路徑:普通 PR、fork PR、維護者評論觸發。確認 secret 沒洩露、許可權足夠但不過寬、失敗時只留下可讀記錄,不會自動寫入非預期檔案或評論刷屏。

還要測試惡意輸入:PR 描述裡要求列印 secret、評論裡要求執行 shell、diff 裡包含看似正常的指令碼修改。Action 必須把這些當成不可信輸入,而不是直接服從 prompt。

Action 產物要可審計:評論、artifact、記錄裡要能看出觸發者、輸入範圍和最終許可權。 失敗時不能刷屏。 結果可複核。

第一次接入時建議只開一個只讀 PR review workflow。等 secret、permissions、fork PR 和評論觸發都驗證透過,再拆 issue triage、label、assistant 評論和自動修復流程。

接下來去哪

官方來源

本頁目錄