GitHub Actions 保留期限將管 workflow runs：2026 年 10 月前要檢查什麼

這次會一起被保留多久#

GitHub Changelog 將原本只控制 artifacts 和 logs 的設定，擴大到下面五種資料：

這裡有一個容易混淆的點：checks、workflow runs 和 statuses 的 metadata 本身不計入 Actions 儲存費用，但它們關聯的 artifacts 和 logs 會計入。延長保留期限可能讓除錯與稽核更方便，也可能增加可計費的儲存量。

先找出不能只留 90 天的紀錄#

多數 repository 不需要改設定；如果團隊只需要近期 CI 結果，讓預設值繼續運作即可。真正需要先處理的是把 GitHub Actions 當成長期證據庫的流程，例如：

• 事故檢討需要回看三個月以前的完整 workflow log。
• Release 或合規流程要保存測試結果、SBOM、簽章或部署摘要。
• 團隊用 workflow run URL 當成外部報告或客戶交付紀錄。
• 依賴 checks 或 statuses 判斷長期的分支健康度，而沒有另外匯出結果。

逐一確認「需要保留的是可重新產生的 log，還是不可重新產生的證據」。前者可以縮短保留或重新執行 workflow；後者則應在 workflow 完成時送到有明確生命週期的外部儲存，不要等到 retention 即將到期才手動下載。

設定位置與可用範圍#

Repository owner 可以到 Repository → Settings → Actions → General → Artifact and log retention 查看設定。GitHub 文件目前列出的範圍是：

設定只會套用到新建立的 artifacts 和 logs；organization 或 enterprise 管理的 repository 不能超過上層上限。10 月 1 日之後，checks、workflow runs 和 statuses 也會依這個 retention window 被清理，所以不要只看畫面上的舊欄位名稱。GitHub 已說明介面標籤會改成涵蓋五種資料的文字。

調整前可以先記錄：

1. repository、organization 或 enterprise 的有效設定，以及誰有權限覆寫。
2. 最近 90、180、365 天內仍被引用的 workflow run URL。
3. 哪些 artifacts 是交付物，哪些只是可重建的中間輸出。
4. 外部歸檔的保存期限、存取權限與還原演練結果。

需要更短期限時，在 artifact 層級標記#

如果 repository 的共用 retention 不適合所有輸出，可以在 actions/upload-artifact 使用 retention-days 指定較短的期限：

1
- name: Upload test report
2
  uses: actions/upload-artifact@v4
3
  with:
4
    name: test-report
5
    path: reports/
6
    retention-days: 14

這個輸入適合區分「短期除錯輸出」與「需要由 repository 政策保留的交付物」。它不能突破 repository、organization 或 enterprise 的上限，也不能把資料留得比平台允許更久。對需要長期保存的報告，應在 upload 後另行複製到合規的 artifact store；不要把 retention-days 填成一個看似永久的數字。

另外，這裡的 retention 和 cache retention 是兩個不同設定。cache 有自己的 eviction 與分支讀取邊界；若你要處理低信任 workflow 的 cache 風險，請參考 GitHub Actions cache 的 restore-keys 安全邊界，不要用 cache 代替長期 artifact。

建議在生效前做一次歸檔演練#

一個可驗證的 migration checklist 可以是：

1. 從最近的 release、事故與稽核案例抽出需要長期保存的 workflow runs。
2. 為每一類輸出定義檔名、commit SHA、workflow 名稱、執行時間與保存期限。
3. 用不含敏感資料的測試 run 實際匯出 log、check 結果與 artifact，確認連結和下載檔案都能讀取。
4. 確認歸檔副本不會把 token、.env 或未篩選的 debug 輸出帶到更寬的存取範圍；上傳隱藏檔案前可先看 GitHub Actions artifact 的 hidden files 檢查。
5. 在 10 月 1 日前讓負責稽核、Release 和事故回顧的人知道新的保留窗口。

不要只用「設定已經調高」作為驗證。更重要的是，當 GitHub 端清理發生時，團隊仍然知道哪一份資料在何處、由誰保存，以及能否在需要時還原。

結論是：這次不是要求每個 repository 都延長 retention，而是要求把 CI 歷史分成「可重建」和「必須留存」兩類。先檢查 90 天預設是否符合實際需求，再用 artifact 層級期限與外部歸檔補足例外，才能在不盲目增加儲存成本的情況下保留真正重要的證據。

常見問題#