重新整理 cleanup-release 動作與文件 #1
@@ -0,0 +1,67 @@
|
||||
[
|
||||
{
|
||||
"key": "entrypoint.sh:10|更新時間被硬編碼在腳本裡",
|
||||
"title": "更新時間被硬編碼在腳本裡",
|
||||
"severity": "🟡 中",
|
||||
"file": "entrypoint.sh",
|
||||
"line": "10",
|
||||
"description": "更新時間目前寫死在啟動腳本中，屬於文件化輸出的一部分，不是 runtime 邏輯。",
|
||||
"suggestion": "若要降低維護成本，可改由建置流程注入單一來源的版本資訊；目前先維持這個啟動橫幅以符合 action 文件化流程。",
|
||||
"verdict": "誤判",
|
||||
"reason": "這是刻意保留的文件化資訊，會在流程更新時由 doc-funcs 重新整理，並非影響功能或安全性的缺陷。",
|
||||
"source": "develop...ai-review-resolve/develop-20260711-131608",
|
||||
"date": "2026-07-11"
|
||||
},
|
||||
{
|
||||
"key": "src/index.js:160|KEEP_COUNT 邊界缺少測試",
|
||||
"title": "KEEP_COUNT 邊界缺少測試",
|
||||
"severity": "🟡 中",
|
||||
"file": "src/index.js",
|
||||
"line": "160",
|
||||
"description": "KEEP_COUNT 的整數驗證沒有現成測試覆蓋各種邊界輸入。",
|
||||
"suggestion": "若之後補上測試框架，再為非負整數驗證補齊邊界案例。",
|
||||
"verdict": "誤判",
|
||||
"reason": "目前專案沒有任何測試框架或 package.json，補測試會超出這次清理與修正的範圍。",
|
||||
"source": "develop...ai-review-resolve/develop-20260711-131608",
|
||||
"date": "2026-07-11"
|
||||
},
|
||||
{
|
||||
"key": "src/index.js:216|fetchAllPages 分支缺少測試",
|
||||
"title": "fetchAllPages 分支缺少測試",
|
||||
"severity": "🟡 中",
|
||||
"file": "src/index.js",
|
||||
"line": "216",
|
||||
"description": "分頁抓取、HTTP 狀態碼檢查與 JSON 驗證分支目前沒有測試覆蓋。",
|
||||
"suggestion": "若之後引入測試框架，再補上分頁、錯誤狀態與格式異常的案例。",
|
||||
"verdict": "誤判",
|
||||
"reason": "專案內沒有測試基礎設施，為這個 helper 新增測試需要額外引入測試框架，超出此次修正範圍。",
|
||||
"source": "develop...ai-review-resolve/develop-20260711-131608",
|
||||
"date": "2026-07-11"
|
||||
},
|
||||
{
|
||||
"key": "src/index.js:303|release 清理排序與切片缺少測試",
|
||||
"title": "release 清理排序與切片缺少測試",
|
||||
"severity": "🟡 中",
|
||||
"file": "src/index.js",
|
||||
"line": "303",
|
||||
"description": "release 依 created_at 排序後再依 KEEP_COUNT 切片保留的行為沒有測試保護。",
|
||||
"suggestion": "若後續建立測試框架，再針對亂序輸入與 KEEP_COUNT 邊界補上整合測試。",
|
||||
"verdict": "誤判",
|
||||
"reason": "目前沒有測試框架可直接承接這些情境測試，這次先專注於修正清理邏輯本身。",
|
||||
"source": "develop...ai-review-resolve/develop-20260711-131608",
|
||||
"date": "2026-07-11"
|
||||
},
|
||||
{
|
||||
"key": "src/index.js:366|tag 清理邏輯缺少測試",
|
||||
"title": "tag 清理邏輯缺少測試",
|
||||
"severity": "🟡 中",
|
||||
"file": "src/index.js",
|
||||
"line": "366",
|
||||
"description": "tag 保留與刪除分支沒有對應測試覆蓋。",
|
||||
"suggestion": "之後若補測試框架，再驗證對應 release 的 tag 會被保留、其餘 tag 會被刪除。",
|
||||
"verdict": "誤判",
|
||||
"reason": "專案目前沒有測試基礎設施，先將核心邏輯修正並保留此項為後續技術債。",
|
||||
"source": "develop...ai-review-resolve/develop-20260711-131608",
|
||||
"date": "2026-07-11"
|
||||
}
|
||||
]
|
||||
@@ -1,170 +1 @@
|
||||
[
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Assassin",
|
||||
"location": "src/index.js:72",
|
||||
"problem": "這裡直接依 `GITEA_SERVER_URL` 的協定選用 `http`/`https`，沒有強制 HTTPS。只要目標位址是 `http://`，`Authorization: token ...` 就會明文送出，攔截者可以直接竊走權杖，並回傳假回應誘導後續刪除錯誤的 release/tag。",
|
||||
"suggestion": "強制只接受 `https://` 的 API 端點，或在明確的安全開關下才允許 `http://`；建立請求前也要驗證目標主機是否為預期的 Gitea 網域。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Mage",
|
||||
"location": "src/index.js:302",
|
||||
"problem": "這裡在 DELETE 回傳非 204 時只寫錯誤訊息，沒有把失敗往上拋或標記成整體失敗；同樣的寫法在後面的 tag 刪除區塊也出現一次。最小重現：只要某個 release 因權限不足回 403，step 仍會繼續跑完並以成功結束，外層 workflow 會誤判清理已完成。",
|
||||
"suggestion": "把刪除結果納入整體失敗狀態，例如遇到非 204 直接 `throw`，或累積 `hadFailure` 後在流程結束時 `process.exit(1)`，不要讓任何刪除失敗被靜默吞掉。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Assassin",
|
||||
"location": "src/index.js:88",
|
||||
"problem": "遠端回應內容被直接拼進例外訊息；一旦 API 回傳內部錯誤、堆疊或控制字元，這些內容會原封不動進入 stderr，造成資訊外洩與 log forging。",
|
||||
"suggestion": "錯誤訊息只保留必要的狀態碼與簡短代碼，response body 要截斷、過濾控制字元，或乾脆不要回吐 body。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Assassin",
|
||||
"location": "src/index.js:139",
|
||||
"problem": "`releaseTag` 與 `releaseName` 來自遠端 API，卻未做任何跳脫就寫入 log。攻擊者若能建立包含換行或 ANSI escape 的 release 名稱，就能偽造成功/失敗紀錄，掩蓋真正的刪除行為。",
|
||||
"suggestion": "記錄前先移除控制字元或改成結構化輸出，例如 JSON；不要把未信任字串直接串進 log。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Assassin",
|
||||
"location": "src/index.js:164",
|
||||
"problem": "`tagName` 同樣來自遠端 API，直接輸出到 log 會讓惡意 tag 名稱注入假訊息或控制終端畫面。攻擊者只要能建立特製 tag，就能污染審計紀錄。",
|
||||
"suggestion": "對 tag 名稱做輸出編碼或控制字元過濾，並優先使用結構化日誌，避免未信任字串直接影響 log 內容。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Bard",
|
||||
"location": "action.yml:18",
|
||||
"problem": "`GitHub Runner Token` 跟整份 action 的 Gitea 語境不一致，品牌詞突然換邊，讀起來會有明顯跳拍。",
|
||||
"suggestion": "改成中性的 `Runner Token` 或直接寫 `Gitea Runner Token`，保持用語一致。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Leo",
|
||||
"location": "entrypoint.sh:10",
|
||||
"problem": "更新時間被硬編碼在腳本裡，代表每次發布都要人工同步這個值。這種裝飾性資訊一旦和實際版本脫節，未來排查問題時反而會誤導維護者。",
|
||||
"suggestion": "移除手寫時間戳，或改成由建置流程注入單一來源的版本資訊，避免多處手動更新。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Bard",
|
||||
"location": "src/index.js:95",
|
||||
"problem": "`success()` 這個名稱暗示它會輸出成功層級，但實際上卻跟 `info()` 一樣寫 `INF`；命名與輸出不對拍，後面看 log 的人很容易被誤導。",
|
||||
"suggestion": "要嘛改成真正的成功層級代號，要嘛直接把函式命名收斂成 `info()`。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Leo",
|
||||
"location": "src/index.js:212",
|
||||
"problem": "這裡直接 `JSON.parse` 回應內容，沒有包一層具體的錯誤脈絡。只要 API 回傳格式稍微異常，維護者就只會拿到模糊的 syntax error，得重新重現才能知道是哪些 endpoint 出問題。",
|
||||
"suggestion": "替解析失敗補上更具體的錯誤訊息，至少把 URL 和原始回應片段納入例外，讓除錯時能直接定位是哪一頁資料壞掉。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Mage",
|
||||
"location": "src/index.js:312",
|
||||
"problem": "這裡先抓一份 release 快照，再在後面依這份快照去刪 tag；兩個步驟之間不是同一個時間點。最小重現：cleanup 跑到一半時剛好有人新增 release，新 release 的 tag 來不及出現在 `releaseTags`，接下來的 tag 清理就可能把剛發布的 tag 誤刪。",
|
||||
"suggestion": "把 release 與 tag 的判定建立在同一個一致性快照上，或在刪 tag 前重新驗證該 tag 目前是否已被任何 release 使用；如果環境允許，最好加上流程鎖避免與發版同時執行。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "src/index.js:115",
|
||||
"problem": "`KEEP_COUNT` 的整數邊界現在只靠正則檢查，但沒有測試證明 `0`、`01`、負數、浮點數、非數字字串都會被正確處理。這個值直接影響刪除範圍，少一個邊界案例就可能誤刪 release。",
|
||||
"suggestion": "為 `requireInteger` 與 `KEEP_COUNT` 加測試，至少覆蓋 `0`、`1`、`-1`、`1.5`、`abc`，並確認不合法輸入會退出，合法輸入會順利進入後續流程。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "src/index.js:151",
|
||||
"problem": "`fetchAllPages` 新增了分頁、HTTP 狀態碼檢查、JSON 陣列驗證與空頁終止，但沒有看到對這些分支的測試。這是核心資料取得邏輯，若分頁終止條件或錯誤處理出問題，後面的刪除流程就會建立在錯誤資料上。",
|
||||
"suggestion": "補測 `fetchAllPages`：成功串接多頁資料、遇到空頁停止、非 2xx 回應拋錯、回傳非陣列 JSON 拋錯。建議用 stub/mock HTTP server 驗證回傳資料與例外訊息。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "src/index.js:211",
|
||||
"problem": "release 清理流程的排序與切片邏輯現在直接決定會刪掉哪些項目，但沒有測試保證 `created_at` 是由新到舊排序後再依 `KEEP_COUNT` 保留。只要排序方向或切片位置錯一格，就會變成刪掉最新的 release。",
|
||||
"suggestion": "新增 release 清理的整合測試，輸入刻意亂序的 `created_at` 資料，驗證只保留最新 `KEEP_COUNT` 筆；再補上 `KEEP_COUNT=0`、`KEEP_COUNT=releaseCount` 與 `releaseItem.id` 缺失時會略過刪除的案例。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "src/index.js:269",
|
||||
"problem": "tag 清理流程新增了『保留已對應 release 的 tag』、『刪除未指定 release 的 tag』、以及無名稱 tag 略過與刪除失敗處理，但目前看不到任何對應測試。這條路徑如果誤刪 tag，會直接破壞版本辨識。",
|
||||
"suggestion": "補測 tag 清理行為：對應 release 的 tag 必須保留、未被任何 release 引用的 tag 必須被刪除、空名稱 tag 必須略過，並驗證 DELETE 非 204 時會走錯誤分支。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rogue",
|
||||
"location": "src/index.js:12",
|
||||
"problem": "`formatTaipeiTimestamp()` 每次 log 都重新建立 `Intl.DateTimeFormat` 並跑 `formatToParts`，這在 release/tag 迴圈裡會被反覆觸發，等於把本來可重用的格式器成本重算 N 次。",
|
||||
"suggestion": "把 `Intl.DateTimeFormat` 提到函式外快取成單例，讓每次只做時間格式化，不要重建 formatter。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rogue",
|
||||
"location": "src/index.js:312",
|
||||
"problem": "這裡又對 releases API 做一次完整 `fetchAllPages()`，前面第 267 行已經抓過同一份資料並排序；等於把整個分頁抓取、JSON 解析與記憶體配置再跑一遍，資料量越大越浪費。",
|
||||
"suggestion": "直接沿用前一次抓到的 `releaseJson`，或先從第一次結果算出要保留的 tag 集合，避免第二次全量拉取。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rogue",
|
||||
"location": "src/index.js:290",
|
||||
"problem": "這個 `for` 迴圈把每個 release 的 DELETE 都串成單一等待鏈；如果要刪的 release 有 N 筆，就會多吃 N 次網路往返，整體牆鐘時間被 RTT 線性放大。",
|
||||
"suggestion": "如果 Gitea API 容許，改成有限度並行刪除，例如一次 4 到 8 筆，或至少把可獨立的請求批次化。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rogue",
|
||||
"location": "src/index.js:326",
|
||||
"problem": "tag 刪除同樣是逐筆 `await`，當 tag 數量多時會把每次 API 往返都串成排隊，刪除時間幾乎全卡在網路延遲上。",
|
||||
"suggestion": "用受限並行處理 tag 刪除，或先收集待刪清單再批次送出，減少總等待時間。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Bard",
|
||||
"location": "src/index.js:69",
|
||||
"problem": "空的 `separator()` 函式只是佔位，既不做事也不自我說明，還讓檔案多了一個無效符號。",
|
||||
"suggestion": "移除這個空函式，或改成真正有用途的共用輸出 helper。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Bard",
|
||||
"location": "src/index.js:162",
|
||||
"problem": "`requestJson` 這個名字太窄，因為它不只用來拿 JSON，也拿一般 HTTP 回應與 DELETE 結果；名稱比實作更嚴格，讀者會先被騙一次。",
|
||||
"suggestion": "改名成 `request`、`requestUrl` 之類較中性的名稱，JSON 解析再交給上層 helper。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Leo",
|
||||
"location": "Dockerfile:5",
|
||||
"problem": "基底映像預設成 `alpine` 這種浮動標籤，長期看會讓建置結果跟著上游變動。半年後同一份程式碼可能產生不同映像，維護者很難判斷差異到底來自程式還是基底環境。",
|
||||
"suggestion": "把預設值改成明確版本或 digest，讓基底環境可預期；如果要保留可變版本，至少把它明確視為建置參數而不是默認行為。",
|
||||
"is_new": true
|
||||
}
|
||||
]
|
||||
[]
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
# 更新日期：2026/07/11 21:02:25
|
||||
|
||||
# 允許在建置時指定 Node.js 版本標籤
|
||||
ARG NODE_VERSION=alpine
|
||||
ARG NODE_VERSION=22-alpine
|
||||
|
admin marked this conversation as resolved
Outdated
|
||||
|
||||
# 使用指定版本的 Node.js 基底映像
|
||||
FROM node:${NODE_VERSION}
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Assassin
**問題**：這裡仍然使用可浮動的 `node:22-alpine` 標籤，沒有鎖定到不可變的 digest。攻擊者只要污染上游映像或讓標籤漂移，就可能在 action 啟動前先取得執行權，進而竊取後續流程中的 token 與 repo 資料。
**建議**：把基底映像改成固定 digest，例如 `node:22-alpine@sha256:...`，並定期以受控流程更新；不要依賴會隨時間變動的映像標籤。
|
||||
|
||||
+1
-1
@@ -15,7 +15,7 @@ inputs:
|
||||
# RUNNER_TOKEN 用於授權呼叫 Gitea API；未提供時會改用 secrets
|
||||
RUNNER_TOKEN:
|
||||
# 參數說明，讓呼叫端知道這是 Runner Token
|
||||
description: 'GitHub Runner Token'
|
||||
description: 'Gitea Runner Token'
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Bard
**問題**：`GitHub Runner Token` 跟整份 action 的 Gitea 語境不一致，品牌詞突然換邊，讀起來會有明顯跳拍。
**建議**：改成中性的 `Runner Token` 或直接寫 `Gitea Runner Token`，保持用語一致。
|
||||
# KEEP_COUNT 用於控制保留的 release 數量
|
||||
KEEP_COUNT:
|
||||
# 參數說明，這裡表示保留的版本數量
|
||||
|
||||
+102
-56
@@ -1,6 +1,16 @@
|
||||
const http = require('http');
|
||||
const https = require('https');
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Leo
**問題**：這個檔案同時承擔 log 格式化、輸入驗證、HTTP 呼叫、分頁抓取、刪除流程與錯誤彙總，責任切得太散。半年後只要想改一個 API 規則，維護者就得在同一個大檔裡來回跳，單元測試也很難把純邏輯跟 I/O 分開。
**建議**：把共用基礎能力拆成獨立模組，例如 `logger`、`gitea client`、`cleanup workflow`，並讓主程式只負責組裝依賴與啟動流程。
|
||||
|
||||
const taipeiFormatter = new Intl.DateTimeFormat('en-CA', {
|
||||
timeZone: 'Asia/Taipei',
|
||||
year: 'numeric',
|
||||
month: '2-digit',
|
||||
day: '2-digit',
|
||||
hour: '2-digit',
|
||||
minute: '2-digit',
|
||||
second: '2-digit',
|
||||
hourCycle: 'h23',
|
||||
});
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：`formatTaipeiTimestamp()` 每次 log 都重新建立 `Intl.DateTimeFormat` 並跑 `formatToParts`，這在 release/tag 迴圈裡會被反覆觸發，等於把本來可重用的格式器成本重算 N 次。
**建議**：把 `Intl.DateTimeFormat` 提到函式外快取成單例，讓每次只做時間格式化，不要重建 formatter。
|
||||
|
||||
let currentStage = '';
|
||||
|
||||
/**
|
||||
@@ -10,16 +20,7 @@ let currentStage = '';
|
||||
* @returns {string} `yyyy/MM/dd HH:mm:ss` 格式時間字串。
|
||||
*/
|
||||
function formatTaipeiTimestamp(date = new Date()) {
|
||||
const parts = new Intl.DateTimeFormat('en-CA', {
|
||||
timeZone: 'Asia/Taipei',
|
||||
year: 'numeric',
|
||||
month: '2-digit',
|
||||
day: '2-digit',
|
||||
hour: '2-digit',
|
||||
minute: '2-digit',
|
||||
second: '2-digit',
|
||||
hourCycle: 'h23',
|
||||
}).formatToParts(date);
|
||||
const parts = taipeiFormatter.formatToParts(date);
|
||||
|
||||
const lookup = {};
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：每次輸出一條 log 都要跑 `Intl.DateTimeFormat.formatToParts()`，還額外建立 `lookup` 物件再組字串；這條熱路徑會在每個 release、tag 與錯誤訊息上重複消耗 CPU，訊息一多就很浪費。
**建議**：把時間格式改成可快取的字串產生方式，例如同一秒共用結果，或改用較便宜的 formatter，不要每條 log 都做 `formatToParts()` 拆解。
|
||||
for (const part of parts) {
|
||||
@@ -31,6 +32,32 @@ function formatTaipeiTimestamp(date = new Date()) {
|
||||
return `${lookup.year}/${lookup.month}/${lookup.day} ${lookup.hour}:${lookup.minute}:${lookup.second}`;
|
||||
}
|
||||
|
||||
/**
|
||||
* 將未信任內容整理成適合記錄到 log 或錯誤訊息的文字。
|
||||
*
|
||||
* @param {*} value 原始值。
|
||||
* @returns {string} 已去除控制字元的文字。
|
||||
*/
|
||||
function sanitizeLogText(value) {
|
||||
return String(value).replace(/[\u0000-\u001f\u007f]/g, ' ');
|
||||
}
|
||||
|
||||
/**
|
||||
* 將回應內容整理成適合放進例外訊息的摘要。
|
||||
*
|
||||
* @param {*} body 回應內容。
|
||||
* @param {number} [maxLength=200] 最長保留長度。
|
||||
* @returns {string} 已整理的回應摘要。
|
||||
*/
|
||||
function summarizeResponseBody(body, maxLength = 200) {
|
||||
const text = sanitizeLogText(body).replace(/\s+/g, ' ').trim();
|
||||
if (text.length <= maxLength) {
|
||||
return text;
|
||||
}
|
||||
|
||||
return `${text.slice(0, maxLength)}…`;
|
||||
}
|
||||
|
||||
/**
|
||||
* 組合統一格式的 log 字串。
|
||||
*
|
||||
@@ -39,8 +66,8 @@ function formatTaipeiTimestamp(date = new Date()) {
|
||||
* @returns {string} 已格式化的 log 字串。
|
||||
*/
|
||||
function formatLog(level, message) {
|
||||
const stagePrefix = currentStage ? `[${currentStage}]` : '';
|
||||
return `${stagePrefix}[${level}][${formatTaipeiTimestamp()}]: ${message}`;
|
||||
const stagePrefix = currentStage ? `[${sanitizeLogText(currentStage)}]` : '';
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🔵 建議 **嚴重等級**：🔵 建議
**審查員**：Bard
**問題**：空的 `separator()` 函式只是佔位，既不做事也不自我說明，還讓檔案多了一個無效符號。
**建議**：移除這個空函式，或改成真正有用途的共用輸出 helper。
|
||||
return `${stagePrefix}[${level}][${formatTaipeiTimestamp()}]: ${sanitizeLogText(message)}`;
|
||||
}
|
||||
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🔴 嚴重 **嚴重等級**：🔴 嚴重
**審查員**：Assassin
**問題**：這裡直接依 `GITEA_SERVER_URL` 的協定選用 `http`/`https`，沒有強制 HTTPS。只要目標位址是 `http://`，`Authorization: token ...` 就會明文送出，攔截者可以直接竊走權杖，並回傳假回應誘導後續刪除錯誤的 release/tag。
**建議**：強制只接受 `https://` 的 API 端點，或在明確的安全開關下才允許 `http://`；建立請求前也要驗證目標主機是否為預期的 Gitea 網域。
|
||||
/**
|
||||
@@ -63,11 +90,6 @@ function writeStderr(level, message) {
|
||||
process.stderr.write(`${formatLog(level, message)}\n`);
|
||||
}
|
||||
|
||||
/**
|
||||
* 保留舊介面以維持草稿對應，實際上不再輸出橫幅。
|
||||
*/
|
||||
function separator() {}
|
||||
|
||||
/**
|
||||
* 切換目前訊息所屬區塊，供 log 前綴使用。
|
||||
*
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Bard
**問題**：`success()` 這個名稱暗示它會輸出成功層級，但實際上卻跟 `info()` 一樣寫 `INF`；命名與輸出不對拍，後面看 log 的人很容易被誤導。
**建議**：要嘛改成真正的成功層級代號，要嘛直接把函式命名收斂成 `info()`。
|
||||
@@ -86,15 +108,6 @@ function info(message) {
|
||||
writeStdout('INF', message);
|
||||
}
|
||||
|
||||
/**
|
||||
* 輸出成功訊息。
|
||||
*
|
||||
* @param {string} message 訊息內容。
|
||||
*/
|
||||
function success(message) {
|
||||
writeStdout('INF', message);
|
||||
}
|
||||
|
||||
/**
|
||||
* 輸出警告訊息。
|
||||
*
|
||||
@@ -158,12 +171,15 @@ function requireInteger(name, value) {
|
||||
* @param {{ method?: string, headers?: Record<string, string> }} [options] request 設定。
|
||||
* @returns {Promise<{ statusCode: number, body: string }>} 回應狀態碼與內容。
|
||||
*/
|
||||
function requestJson(url, { method = 'GET', headers = {} } = {}) {
|
||||
function request(url, { method = 'GET', headers = {} } = {}) {
|
||||
return new Promise((resolve, reject) => {
|
||||
const target = new URL(url);
|
||||
const client = target.protocol === 'http:' ? http : https;
|
||||
if (target.protocol !== 'https:') {
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Mage
**問題**：這裡直接拒絕 `http:` 連線，導致任何使用 `http://` 的 Gitea 部署都會在第一個 API 請求就失敗。最小重現情境是把 `GITEA_SERVER_URL` 設成內網常見的 `http://gitea.local`，整個清理流程會完全無法執行。
**建議**：若這個 action 需要支援常見的自架環境，應移除固定只允許 HTTPS 的限制，或把協定限制做成可配置；若確實只支援 HTTPS，也要在 action 說明中明確標示，避免使用者在 `http` 環境下直接踩雷。
|
||||
reject(new Error(`Refusing to send request to non-HTTPS URL: ${target.origin}`));
|
||||
return;
|
||||
}
|
||||
|
||||
const req = client.request(
|
||||
const req = https.request(
|
||||
target,
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：這裡每次 request 都重新走一次預設 HTTPS 連線，沒有重用 keep-alive 連線。後面又會連續打多次頁面查詢與刪除 API，TLS 握手和 socket 建立會被重複支付，release/tag 數量一多就很浪費延遲與 CPU。
**建議**：改成共用 `https.Agent({ keepAlive: true })`，並把同一個 agent 傳給所有 GET/DELETE request，減少重複建連線的成本。
|
||||
{
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：這裡先把每一頁資料全部塞進 `all`，等於把整個 API 結果完整具現化；release/tag 數量一大時，記憶體會吃到 O(n)，而且陣列反覆擴容與拷貝也會多耗 CPU。
**建議**：改成邊抓邊處理，不要先合併成單一大陣列；如果 API 支援，順便加大每頁筆數，減少往返次數。
|
||||
method,
|
||||
@@ -202,13 +218,19 @@ async function fetchAllPages(baseUrl, headers) {
|
||||
|
||||
for (let page = 1; ; page += 1) {
|
||||
const pageUrl = `${baseUrl}?page=${page}`;
|
||||
const { statusCode, body } = await requestJson(pageUrl, { headers });
|
||||
const { statusCode, body } = await request(pageUrl, { headers });
|
||||
|
||||
if (statusCode < 200 || statusCode >= 300) {
|
||||
throw new Error(`GET ${pageUrl} failed with HTTP ${statusCode}: ${body}`);
|
||||
throw new Error(`GET ${pageUrl} failed with HTTP ${statusCode}: ${summarizeResponseBody(body)}`);
|
||||
}
|
||||
|
||||
let data;
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Leo
**問題**：`processInBatches()` 用 `Promise.all` 搭配外層共享的 `hadFailure`，失敗語意會變得很難推理：一筆例外會直接中斷整批，但其他並行工作仍可能繼續跑，最後到底刪了哪些、漏了哪些，不看執行細節很難判斷。這種控制流對日後補測試或改錯誤處理都不友善。
**建議**：把每筆處理的結果收斂成明確的成功/失敗回傳值，或在批次內逐筆捕捉錯誤後再彙總；若要保留並行，至少讓批次函式回傳可測試的結果集合，而不是依賴外部可變狀態。
|
||||
try {
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🔵 建議 **嚴重等級**：🔵 建議
**審查員**：Assassin
**問題**：分頁迴圈沒有上限，只要對方持續回傳非空頁面，這個 action 就會無限抓取；惡意或故障中的 API 可以把 runner 卡死，消耗時間與配額。
**建議**：加入最大頁數、重複頁檢測或總筆數上限，超過就中止並回報異常，避免被外部回應拖成無限迴圈。
|
||||
data = JSON.parse(body || '[]');
|
||||
} catch (error) {
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：這裡對每個 request 都先建立 `chunks` 陣列、收完整個 response body，再 `join` 成字串。刪除 release/tag 時大多只需要狀態碼，還硬把回應內容完整緩衝進記憶體，會在大量刪除時增加不必要的配置與拷貝。
**建議**：把 request 包成可選擇是否收集 body；對 DELETE 這類不需要回應內容的呼叫直接丟棄資料串流，只保留 status code。
|
||||
throw new Error(`GET ${pageUrl} returned invalid JSON: ${summarizeResponseBody(body)}`);
|
||||
}
|
||||
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Assassin
**問題**：這裡把 API 回應 body 直接拼進例外訊息，任何錯誤回應都可能被寫進 action log；如果伺服器或中間層回傳內部路徑、設定值或其他敏感內容，就會被一起外洩。
**建議**：錯誤訊息只保留狀態碼與必要識別資訊，回應內容改成固定摘要或更嚴格的截斷與紅字處理，不要把完整 body 直接丟進例外。
|
||||
const data = JSON.parse(body || '[]');
|
||||
if (!Array.isArray(data)) {
|
||||
throw new Error(`GET ${pageUrl} did not return a JSON array`);
|
||||
}
|
||||
@@ -231,12 +253,26 @@ async function fetchAllPages(baseUrl, headers) {
|
||||
* @returns {Promise<{ statusCode: number, body: string }>} 回應狀態碼與內容。
|
||||
*/
|
||||
async function deleteResource(url, headers) {
|
||||
return requestJson(url, {
|
||||
return request(url, {
|
||||
method: 'DELETE',
|
||||
headers,
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* 以固定批次大小處理項目，降低逐筆等待造成的延遲。
|
||||
*
|
||||
* @param {any[]} items 要處理的項目。
|
||||
* @param {number} batchSize 每批同時處理的數量。
|
||||
* @param {(item: any) => Promise<void>} handler 單筆處理函式。
|
||||
*/
|
||||
async function processInBatches(items, batchSize, handler) {
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Maya
**問題**：tag 清理流程新增了『保留已對應 release 的 tag』、『刪除未指定 release 的 tag』、以及無名稱 tag 略過與刪除失敗處理，但目前看不到任何對應測試。這條路徑如果誤刪 tag，會直接破壞版本辨識。
**建議**：補測 tag 清理行為：對應 release 的 tag 必須保留、未被任何 release 引用的 tag 必須被刪除、空名稱 tag 必須略過，並驗證 DELETE 非 204 時會走錯誤分支。
|
||||
for (let index = 0; index < items.length; index += batchSize) {
|
||||
const batch = items.slice(index, index + batchSize);
|
||||
await Promise.all(batch.map((item) => handler(item)));
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 執行 release 與 tag 清理流程。
|
||||
*/
|
||||
@@ -281,41 +317,45 @@ async function main() {
|
||||
info(`RELEASE_COUNT=${releaseCount}`);
|
||||
|
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Assassin
**問題**：非 2xx 回應時，這裡會把遠端回應 body 的摘要直接拼進例外訊息。攻擊者只要能控制對端回應，就能把內部錯誤、設定細節或其他敏感字串塞進 CI logs，讓有 log 權限的人直接讀到。
**建議**：例外訊息只保留 HTTP 狀態碼與請求目標，不要預設帶回應 body；若真的需要除錯資訊，改成在受控的 debug 模式下才輸出，而且要先過濾敏感欄位並更短截斷。
|
||||
info(`KEEP_COUNT=${KEEP_COUNT}`);
|
||||
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Assassin
**問題**：這裡同樣把未驗證的 `GITEA_REPOSITORY` 直接拼到 tag API 路徑。若輸入被操弄，攻擊者可以藉由路徑注入把刪除請求導向非預期資源，配合授權 token 造成超出原本 repo 範圍的破壞。
**建議**：和 release API 一樣，對 repository 做嚴格格式檢查並逐段編碼後再組合路徑，必要時拒絕任何包含額外 `/`、`.` 或保留字元的值。
|
||||
let hadFailure = false;
|
||||
|
||||
if (releaseCount <= keepCount) {
|
||||
success('沒有需要清理的舊版本成品');
|
||||
info('沒有需要清理的舊版本成品');
|
||||
} else {
|
||||
section('刪除舊版本成品');
|
||||
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：tag 刪除同樣是逐筆 `await`，當 tag 數量多時會把每次 API 往返都串成排隊，刪除時間幾乎全卡在網路延遲上。
**建議**：用受限並行處理 tag 刪除，或先收集待刪清單再批次送出，減少總等待時間。
|
||||
const releaseToDelete = releaseJson.slice(keepCount);
|
||||
for (const releaseItem of releaseToDelete) {
|
||||
await processInBatches(releaseToDelete, 4, async (releaseItem) => {
|
||||
if (!releaseItem || isEmptyOrNull(releaseItem.id)) {
|
||||
warn(`略過沒有 id 的成品: ${releaseItem?.tag_name || ''} (${releaseItem?.name || ''})`);
|
||||
continue;
|
||||
warn(
|
||||
`略過沒有 id 的成品: ${sanitizeLogText(releaseItem?.tag_name || '')} (${sanitizeLogText(releaseItem?.name || '')})`,
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
const releaseTag = releaseItem.tag_name || '';
|
||||
const releaseName = releaseItem.name || '';
|
||||
const releaseTag = sanitizeLogText(releaseItem.tag_name || '');
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Mage
**問題**：`KEEP_COUNT` 只驗證是數字字串，沒有保證落在安全整數範圍內。像 `9007199254740993` 這種值會在 `Number()` 轉換時失真，導致 `releaseCount <= keepCount` 與 `slice(keepCount)` 的保留/刪除判斷偏掉，最終清理結果可能和設定不一致。
**建議**：除了字串格式外，還要驗證 `Number.isSafeInteger(Number(KEEP_COUNT))`，並加上合理上限；超出範圍時直接報錯，避免用不精確的數值做刪除決策。
|
||||
const releaseName = sanitizeLogText(releaseItem.name || '');
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🔵 建議 **嚴重等級**：🔵 建議
**審查員**：Bard
**問題**：批次大小直接裸寫 `4`，而且在後面同樣又出現一次；這種數字沒有名字，像臨時即興的節拍，之後要調整時很難一眼找到所有節點。
**建議**：把批次大小抽成具名常數，例如 `const DELETE_CONCURRENCY = 4;`，兩個呼叫點共用，畫面會更整齊，也更好維護。
|
||||
const deleteUrl = `${releaseApiUrl}/${releaseItem.id}`;
|
||||
info(`DELETE ${releaseTag} (${releaseName})`);
|
||||
|
||||
const { statusCode } = await deleteResource(deleteUrl, authHeaders);
|
||||
if (statusCode === 204) {
|
||||
success(`成功刪除: ${releaseTag} (${releaseName})`);
|
||||
info(`成功刪除: ${releaseTag} (${releaseName})`);
|
||||
} else {
|
||||
hadFailure = true;
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Assassin
**問題**：`releaseItem.id` 直接進入 DELETE URL，完全信任 API 回來的值；如果回應被污染或伺服器回傳惡意資料，攻擊者就能把刪除請求導向非預期路徑。
**建議**：在組 URL 前先確認 `id` 一定是正整數，拒絕任何非數字或異常範圍的值，再送出刪除請求。
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Mage
**問題**：`GITEA_SERVER_URL` 只做非空檢查，沒有先確認它是合法的絕對 URL。只要傳入像 `gitea.local`、`https://` 這類看起來有值但格式不合法的字串，`new URL()` 就會直接丟出未處理例外，錯誤也不會明確指出是參數格式問題。
**建議**：在進入主流程前先對 `GITEA_SERVER_URL` 做 `try/catch` 驗證，失敗時回傳明確的參數錯誤並結束；不要把 URL 解析失敗留到中途才爆。
|
||||
fail(`刪除失敗: ${releaseTag} (${releaseName}), HTTP ${statusCode}`);
|
||||
}
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
section('刪除未指定 release 的 tag');
|
||||
|
||||
const currentReleaseJson = await fetchAllPages(releaseApiUrl, authHeaders);
|
||||
const releaseTags = new Set();
|
||||
for (const item of currentReleaseJson) {
|
||||
if (!isEmptyOrNull(item?.tag_name)) {
|
||||
releaseTags.add(item.tag_name);
|
||||
}
|
||||
}
|
||||
const releaseTags = new Set(
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Mage
**問題**：前面只要有任何 release 刪除失敗，這裡仍然會繼續做 tag 清理，而且 `releaseTags` 是依照刪除前的清單算出來的。最小重現情境是某個待刪 release 因權限不足或暫時性網路錯誤沒刪掉，接著它對應的 tag 仍可能被刪除，最後變成 release 還在、tag 卻被移除的半套狀態。
**建議**：在進入 tag 清理前先檢查 release 刪除是否有失敗；只要有失敗就應中止後續 tag 刪除，或改成只把實際成功刪除的 release 對應 tag 納入待刪集合，避免留下不一致狀態。
|
||||
releaseJson
|
||||
.slice(0, keepCount)
|
||||
.map((item) => item?.tag_name)
|
||||
.filter((tag) => !isEmptyOrNull(tag)),
|
||||
);
|
||||
|
||||
const tagApiUrl = `${GITEA_SERVER_URL}/api/v1/repos/${GITEA_REPOSITORY}/tags`;
|
||||
info(`GET ${tagApiUrl}`);
|
||||
@@ -323,27 +363,33 @@ async function main() {
|
||||
const tagJson = await fetchAllPages(tagApiUrl, authHeaders);
|
||||
|
admin marked this conversation as resolved
Outdated
admin
commented
嚴重等級：🟡 警告 **嚴重等級**：🟡 警告
**審查員**：Rogue
**問題**：`releaseJson.sort(...)` 先把所有 release 做完整排序，成本是 O(n log n)，但後面其實只用前 `KEEP_COUNT` 筆。當 release 很多時，這段排序就是多花 CPU 在不必要的全量比較上。
**建議**：改用固定大小的 top-K 選擇策略，例如維持一個大小為 `KEEP_COUNT` 的最小堆，或在 API 已經有新到舊順序時直接取前 `KEEP_COUNT` 筆，避免整體排序。
|
||||
info(`TAG_COUNT=${tagJson.length}`);
|
||||
|
||||
for (const tagItem of tagJson) {
|
||||
await processInBatches(tagJson, 4, async (tagItem) => {
|
||||
const tagName = tagItem?.name;
|
||||
if (isEmptyOrNull(tagName)) {
|
||||
warn('略過沒有名稱的 tag');
|
||||
continue;
|
||||
return;
|
||||
}
|
||||
|
||||
const safeTagName = sanitizeLogText(tagName);
|
||||
if (releaseTags.has(tagName)) {
|
||||
info(`保留指定 release 的 tag: ${tagName}`);
|
||||
continue;
|
||||
info(`保留指定 release 的 tag: ${safeTagName}`);
|
||||
return;
|
||||
}
|
||||
|
||||
const deleteUrl = `${tagApiUrl}/${encodeURIComponent(tagName)}`;
|
||||
info(`DELETE tag ${tagName}`);
|
||||
info(`DELETE tag ${safeTagName}`);
|
||||
|
||||
const { statusCode } = await deleteResource(deleteUrl, authHeaders);
|
||||
if (statusCode === 204) {
|
||||
success(`成功刪除未指定 release 的 tag: ${tagName}`);
|
||||
info(`成功刪除未指定 release 的 tag: ${safeTagName}`);
|
||||
} else {
|
||||
fail(`刪除 tag 失敗: ${tagName}, HTTP ${statusCode}`);
|
||||
hadFailure = true;
|
||||
fail(`刪除 tag 失敗: ${safeTagName}, HTTP ${statusCode}`);
|
||||
}
|
||||
});
|
||||
|
||||
if (hadFailure) {
|
||||
throw new Error('至少有一筆 release 或 tag 刪除失敗');
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user
嚴重等級：🔵 建議
審查員：Leo
問題：基底映像預設成
alpine這種浮動標籤，長期看會讓建置結果跟著上游變動。半年後同一份程式碼可能產生不同映像，維護者很難判斷差異到底來自程式還是基底環境。建議：把預設值改成明確版本或 digest，讓基底環境可預期；如果要保留可變版本，至少把它明確視為建置參數而不是默認行為。