GitHub Actions API 更新簡化開發者的工作流程追蹤

Peter Zhang 2026年2月19日 23:29

GitHub 的工作流程調度 API 現在會返回執行 ID，在以程式化方式觸發自動化工作流程時，不再需要自訂輪詢解決方案。

GitHub 悄悄解決了開發者在自動化 CI/CD 管線時遇到的一個令人困擾的痛點。工作流程調度 API 端點現在會在其回應中直接返回執行 ID——這個小改變消除了數小時的替代方案程式碼。

以前，透過 API 觸發工作流程只會給你一個 204 No Content 狀態。你知道工作流程已啟動，但如果不重複輪詢 API 或建立自訂追蹤系統，很難弄清楚哪個執行是你的。這個問題現在已經解決了。

這次更新於 2026 年 2 月 19 日宣布，引入了一個名為 return_run_details 的新可選參數。將其設為 true，你將獲得包含工作流程 ID、API URL 和工作流程 URL 的 200 OK 回應。跳過該參數，舊的 204 行為將繼續——保留了向後相容性。

執行 2.87.0 版本或更高版本的 GitHub CLI 使用者會自動獲得此功能。執行 gh workflow run，你將看到建立的執行 URL，以及用於檢查它的 gh run view 命令。CLI 現在將 return_run_details 預設為 true。

這對於在 GitHub Actions 之上建立自動化的任何人都很重要。想想部署編排系統、批次處理管線，或任何需要追蹤其產生內容的工具。以前的方法——輪詢執行端點並嘗試匹配時間戳或提交 SHA——既脆弱又消耗速率限制。

時機值得注意。GitHub 在兩天前的 2 月 17 日預覽了其 Agentic Workflows 概念,表明在程式化工作流程控制方面進行了更深入的投資。而且該平台仍在從 2 月 2 日影響託管執行器的重大中斷中恢復聲譽，該中斷擾亂了整個生態系統的 CI/CD 管線。

就背景而言，GitHub 在 2025 年 12 月將 workflow_dispatch 輸入的最大值從 10 增加到 25，這是針對複雜自動化場景的另一項生活品質改進。

該功能現已在 REST API 中上線。對於準備放棄自訂追蹤技巧的任何人，可以在 GitHub 的 Actions 工作流程事件指南中查看文件。

圖片來源：Shutterstock

GitHub Actions API 更新簡化開發者工作流程追蹤