Hugging Face 的 LOGO

MCP 課程文件

模組 2：GitHub Actions 整合

Hugging Face's logo
加入 Hugging Face 社群

並獲得增強的文件體驗

開始使用

模組 2：GitHub Actions 整合

靜默故障的襲擊

CodeCraft Studios 第二週。您在模組 1 中構建的 PR 代理已經在幫助開發人員編寫更好的拉取請求——Sarah 最新的 PR 有一個清晰的描述，為 Mike 節省了 20 分鐘的調查時間。團隊歡欣鼓舞！

但隨後災難降臨。

週五下午，一個關鍵的 bug 達到了生產環境。支付系統崩潰，客戶抱怨，團隊爭先恐後地進行調查。經過兩個小時的緊張工作，他們發現了根本原因：週二 CI 執行中的一個測試失敗，但沒有人注意到。

“我們怎麼會漏掉這個？”團隊負責人一邊滾動 GitHub Actions 一邊問道。“測試顯然失敗了，但是有 47 個倉庫和每天幾十次提交，誰有時間檢查每個構建？”

團隊意識到他們需要對其 CI/CD 管道的即時可見性，但手動檢查所有專案中的 GitHub Actions 是不可擴充套件的。他們需要自動化來監控問題並立即發出警報。

您的任務：擴充套件您的 MCP 伺服器，使其具備 Webhook 功能，以監控 GitHub Actions，絕不再讓任何故障悄然溜走。

您將構建什麼

本模組彌合了靜態檔案分析（模組 1）和動態團隊通知（模組 3）之間的鴻溝。您將新增即時功能，將您的 PR 代理轉變為一個全面的開發監控系統。

在模組 1 中建立的基礎之上，您將新增

  • Webhook 伺服器，用於接收 GitHub Actions 事件
  • 新工具，用於監控 CI/CD 狀態
  • MCP 提示，提供一致的工作流模式
  • 與您的 GitHub 倉庫的即時整合

截圖：即時 CI/CD 監控實戰！🎯

設定：觀看 CodeCraft Studios 的新系統如何在故障到達生產環境之前捕獲它們

  1. GitHub Webhooks - 查看向您的伺服器傳送事件的實際 Webhook 配置
  2. 失敗測試 - 那些以前未被注意到的紅色 X？不再是了！
  3. 本地開發 - Webhook 伺服器和 Cloudflare Tunnel 協同工作

即時 MCP 魔法：Claude 響應三個關鍵請求

  • “我們收到了哪些 GitHub Actions 事件？” - Claude 使用您的新工具檢查近期活動
  • “分析 CI 結果” - 觀看 Claude 深入分析測試失敗並提供可操作的見解
  • “建立部署摘要” - 檢視 MCP 提示如何引導 Claude 建立團隊友好的更新

靜默故障不再 🚨：還記得週二測試失敗中的那個關鍵 bug 嗎？有了這個系統，Claude 會立即捕獲它。截圖準確展示了您的 MCP 伺服器如何將 GitHub 的原始 Webhook 資料轉化為清晰、可操作的警報。

是什麼讓這變得特別：您的模組 1 PR 代理是靜態的——它在被要求時分析程式碼。而模組 2 的增強是動態的——它 24/7 監控您的 CI/CD 管道，並幫助 Claude 提供即時見解。不再有周五下午的驚喜！

學習目標

本模組結束時，您將理解

  1. 如何與 MCP 伺服器一起執行 Webhook 伺服器
  2. 如何接收和處理 GitHub Webhook
  3. 如何為標準化工作流建立 MCP 提示
  4. 如何使用 Cloudflare Tunnel 進行本地 Webhook 測試

先決條件

您將直接在模組 1 的工作基礎上進行構建，因此請確保您已具備以下條件：

  • 完成模組 1：構建 MCP 伺服器 - 您將擴充套件相同的程式碼庫
  • 對 GitHub Actions 的基本理解 - 您應該瞭解 CI/CD 工作流是什麼
  • 一個啟用了 Actions 的 GitHub 倉庫 - 即使是簡單的 workflow 檔案也可以
  • 已安裝 Cloudflare Tunnel (cloudflared) - 這將把您的本地 Webhook 伺服器暴露給 GitHub

關鍵概念

MCP 提示

提示是可重用的模板，用於引導 Claude 完成複雜的工作流。與工具（Claude 自動呼叫）不同，提示是由使用者啟動的，並提供結構化的指導。

示例用例

  • 一致地分析 CI/CD 結果
  • 建立標準化的部署摘要
  • 系統地排除故障

Webhook 整合

您的 MCP 伺服器將執行兩個服務

  1. MCP 伺服器（與 Claude 通訊）
  2. 一個執行在 8080 埠的 Webhook 伺服器（接收 GitHub 事件）

這使得 Claude 能夠對即時 CI/CD 事件做出反應！

架構洞察：為 MCP 通訊和 Webhook 處理執行獨立的服務是一種清晰的關注點分離。Webhook 伺服器處理 HTTP 的複雜性，而您的 MCP 伺服器專注於資料分析和 Claude 整合。

專案結構

github-actions-integration/
├── starter/          # Your starting point
│   ├── server.py     # Module 1 code + TODOs
│   ├── pyproject.toml
│   └── README.md
└── solution/         # Complete implementation
    ├── server.py     # Full webhook + prompts
    ├── pyproject.toml
    └── README.md

實施步驟

步驟 1：設定並執行 Webhook 伺服器

與模組 1 中您使用現有檔案不同，本模組引入了即時事件處理。起始程式碼包含：

  • 您的模組 1 實現 - 您所有的現有 PR 分析工具
  • 一個完整的 Webhook 伺服器 (webhook_server.py) - 已準備好接收 GitHub 事件

  1. 安裝依賴項（與模組 1 相同）

    uv sync

  2. 啟動 Webhook 伺服器（在新終端中）

    python webhook_server.py

該伺服器將接收 GitHub Webhook 並將其儲存在 github_events.json 中。

Webhook 事件儲存的工作原理

  • 每個傳入的 GitHub Webhook（push、pull request、workflow 完成等）都會附加到 JSON 檔案中
  • 事件與時間戳一起儲存，便於查詢近期活動
  • 該檔案充當一個簡單的事件日誌，您的 MCP 工具可以讀取和分析它
  • 無需資料庫 - 所有內容都以簡單、可讀的 JSON 格式儲存

步驟 2：連線到事件儲存

現在，您將您的 MCP 伺服器（來自模組 1）連線到 Webhook 資料。這比直接處理 HTTP 請求簡單得多——Webhook 伺服器承擔了所有繁重的工作，並將事件儲存在 JSON 檔案中。

新增讀取 Webhook 事件的路徑

# File where webhook server stores events
EVENTS_FILE = Path(__file__).parent / "github_events.json"

Webhook 伺服器處理所有 HTTP 細節——您只需讀取 JSON 檔案即可！這種關注點分離使您的 MCP 伺服器專注於其最擅長的領域。

開發提示：使用檔案而不是 HTTP 請求可以使測試變得更容易。您可以手動向 github_events.json 中新增事件，無需設定 Webhook 即可測試您的工具。

步驟 3：新增 GitHub Actions 工具

就像模組 1 中您建立用於檔案分析的工具一樣，現在您將建立用於 CI/CD 分析的工具。這些工具將與您現有的 PR 分析工具協同工作，為 Claude 提供程式碼更改和構建狀態的完整檢視。

注意：起始程式碼已經包含了模組 1 中的輸出限制修復，因此您不會遇到令牌限制錯誤。請專注於本模組中的新概念！

實施兩個新工具

  1. get_recent_actions_events:

    • 從 EVENTS_FILE 讀取
    • 返回最新事件（最多限制數量）
    • 如果檔案不存在，則返回空列表

  2. get_workflow_status:

    • 從檔案讀取所有事件
    • 按 workflow_run 事件篩選
    • 按工作流名稱分組並顯示最新狀態

這些工具讓 Claude 可以分析您的 CI/CD 管道。

步驟 4：建立 MCP 提示

現在您將新增您的第一個 MCP 提示！與工具（Claude 自動呼叫）不同，提示是幫助使用者與 Claude 持續互動的模板。將它們視為引導 Claude 完成複雜工作流的“對話啟動器”。

模組 1 專注於資料訪問工具，而本模組則引入了工作流指導提示。

實施四個演示不同工作流模式的提示

  1. analyze_ci_results：全面的 CI/CD 分析
  2. create_deployment_summary：團隊友好的更新
  3. generate_pr_status_report：組合程式碼 + CI 報告
  4. troubleshoot_workflow_failure：系統化除錯

每個提示都應返回一個字串，其中包含 Claude 要遵循的清晰指令。

步驟 5：使用 Cloudflare Tunnel 進行測試

現在是激動人心的部分——使用真實的 GitHub 事件測試您擴充套件的 MCP 伺服器！您將同時執行多個服務，就像在真實的開發環境中一樣。

  1. 啟動您的 MCP 伺服器（與模組 1 相同的命令）

    uv run server.py

  2. 在另一個終端中，啟動 Cloudflare Tunnel

    cloudflared tunnel --url https://:8080

  3. 使用隧道 URL 配置 GitHub webhook

  4. 使用提示與 Claude Code 進行測試

練習

練習 1：自定義工作流提示

建立一個新提示，透過結合以下內容來幫助進行 PR 審查

  • 模組 1 工具中的程式碼更改
  • 模組 2 工具中的 CI/CD 狀態
  • 審查人員的清單格式

練習 2：事件過濾

增強 get_workflow_status 以

  • 按工作流結論（成功/失敗）篩選
  • 按倉庫分組
  • 顯示上次執行以來的時間

練習 3：通知系統

新增一個工具，該工具可用於

  • 跟蹤哪些事件已被“檢視”
  • 突出顯示新故障
  • 建議通知哪個團隊成員

常見問題

Webhook 未接收到事件

  • 確保 Cloudflare Tunnel 正在執行
  • 檢查 GitHub webhook 設定（應顯示最近的交付）
  • 驗證 payload URL 是否包含 /webhook/github

提示不起作用

  • FastMCP 提示只是返回字串
  • 確保您的函式用 @mcp.prompt() 裝飾

Webhook 伺服器問題

  • 確保 webhook_server.py 在單獨的終端中執行
  • 檢查 8080 埠是否空閒：lsof -i :8080
  • 事件檔案將在接收到第一個事件時自動建立

下一步

幹得漂亮！您已成功為 MCP 伺服器添加了即時功能。您現在擁有一個可以執行以下操作的系統：

  • 分析程式碼更改（來自模組 1）
  • 即時監控 CI/CD 事件（來自本模組）
  • 使用 MCP 提示提供一致的工作流指導
  • 透過清晰的基於檔案的架構處理 Webhook 事件

模組 2 中的主要成就：

  • 構建了您的第一個 Webhook 整合
  • 學習了用於工作流標準化的 MCP 提示
  • 建立了處理即時資料的工具
  • 建立了事件驅動自動化的模式

接下來要做什麼：

  1. 查閱解決方案，路徑為 /projects/unit3/github-actions-integration/solution/，以瞭解不同的實現方法
  2. 實驗您的提示 - 嘗試將它們用於不同型別的 GitHub 事件
  3. 測試整合 - 將您的模組 1 檔案分析工具與模組 2 事件監控在一個對話中結合使用
  4. 進入模組 3 - 您將在其中透過 Slack 整合新增團隊通知來完成自動化管道

模組 3 將把所有內容整合到一個您的團隊可以實際使用的完整工作流中！

故事繼續……

您的監控系統正在執行！CodeCraft Studios 現在可以即時捕獲 CI/CD 故障，團隊對他們的部署更有信心。但下週將迎來新的挑戰：資訊孤島正在導致重複工作和錯失機會。模組 3 將透過智慧團隊通知來完善自動化系統，讓每個人都隨時瞭解最新情況。

附加資源

< > 在 GitHub 上更新

←模組 1：構建 MCP 伺服器 模組 3：Slack 通知→
© . This site is unofficial and not affiliated with Hugging Face, Inc.