old-docker-actions/release-cleanup
2
0
Fork 0
Code Pull Requests Actions Releases 4 Activity

refactor(release-cleanup): 將清理邏輯由 bash 改寫為 Node.js #5

Closed
jiantw83 wants to merge 43 commits from refactor/nodejs-rewrite-20260626-103443 into develop
pull from: refactor/nodejs-rewrite-20260626-103443
merge into: :develop
Conversation 29 Commits 43 Files Changed 23
+7 -2
1 changed files with 7 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 9e33cb8ba8 - Show all commits
app/releases.js
+7 -2
View File
2
 @@ -18,9 +18,14 @@ export function selectReleasesToDelete(releases, keepCount) {
return Number.isNaN(time) ? 0 : time return Number.isNaN(time) ? 0 : time
} }
// 先一次性計算每筆的時間戳,避免在排序比較中重複呼叫 Date.parse。 // 先一次性計算每筆的時間戳,避免在排序比較中重複呼叫 Date.parse。
Ghost marked this conversation as resolved
gitea-actions commented 2026-06-26 03:34:26 +00:00
Review
Copy Link
Copy Source

嚴重等級：🟡 警告
審查員：Leo
問題：在 selectReleasesToDelete 函式中，對於 Date.parse 無法解析的日期直接視為 0，這在資料清理邏輯中是一個隱晦的行為，未來維護者可能不清楚為什麼無效日期會優先被刪除。
建議：應明確記錄無效日期的處理方式（例如記錄 warning），或在 Date.parse 失敗時，應考慮給予一個明確的邏輯（例如拋出錯誤或放到特定排序位置），以減少不可預期的副作用。

**嚴重等級**：🟡 警告 **審查員**：Leo **問題**：在 `selectReleasesToDelete` 函式中，對於 `Date.parse` 無法解析的日期直接視為 `0`，這在資料清理邏輯中是一個隱晦的行為，未來維護者可能不清楚為什麼無效日期會優先被刪除。 **建議**：應明確記錄無效日期的處理方式（例如記錄 warning），或在 `Date.parse` 失敗時，應考慮給予一個明確的邏輯（例如拋出錯誤或放到特定排序位置），以減少不可預期的副作用。
// 時間相同時以 id(數值,大者為新)作為次要鍵,確保排序結果具決定性。
Ghost marked this conversation as resolved Outdated
gitea-actions commented 2026-06-26 02:38:03 +00:00
Outdated
Review
Copy Link
Copy Source

嚴重等級：🔴 嚴重
審查員：Maya
問題：cleanupReleases 是執行刪除舊成品的核心函式，但目前缺乏針對 API 呼叫失敗（如 GET 失敗、DELETE 失敗）的測試，無法驗證錯誤處理邏輯是否如預期運作。
建議：使用測試框架搭配 mock 伺服器回應，補齊 cleanupReleases 的測試案例，特別是驗證當 deleteResource 回傳非 204 狀態碼時，系統是否正確記錄錯誤並繼續或中斷。

**嚴重等級**：🔴 嚴重 **審查員**：Maya **問題**：cleanupReleases 是執行刪除舊成品的核心函式，但目前缺乏針對 API 呼叫失敗（如 GET 失敗、DELETE 失敗）的測試，無法驗證錯誤處理邏輯是否如預期運作。 **建議**：使用測試框架搭配 mock 伺服器回應，補齊 cleanupReleases 的測試案例，特別是驗證當 deleteResource 回傳非 204 狀態碼時，系統是否正確記錄錯誤並繼續或中斷。
return releases return releases
.map((release) => ({ release, time: createdTime(release) })) .map((release) => ({
Ghost marked this conversation as resolved
gitea-actions commented 2026-06-26 03:30:27 +00:00
Review
Copy Link
Copy Source

嚴重等級：🔵 建議
審查員：Rogue
問題：為了排序而進行了多次 map 操作，先將陣列 map 為物件陣列，排序後又 map 回原始物件陣列。這在大數據集下會造成多次 O(n) 的陣列分配與垃圾回收壓力，浪費 CPU 與記憶體週期。
建議：排序時應嘗試減少陣列中間狀態的產生，例如考慮使用原地排序（若不介意原陣列變更）或簡化 mapping 的邏輯。

**嚴重等級**：🔵 建議 **審查員**：Rogue **問題**：為了排序而進行了多次 map 操作，先將陣列 map 為物件陣列，排序後又 map 回原始物件陣列。這在大數據集下會造成多次 O(n) 的陣列分配與垃圾回收壓力，浪費 CPU 與記憶體週期。 **建議**：排序時應嘗試減少陣列中間狀態的產生，例如考慮使用原地排序（若不介意原陣列變更）或簡化 mapping 的邏輯。
gitea-actions commented 2026-06-26 03:34:26 +00:00
Review
Copy Link
Copy Source

嚴重等級：🟡 警告
審查員：Mage
問題：在 selectReleasesToDelete 的排序邏輯中，若多個成品具有完全相同的 created_at 時間戳，目前的排序行為依賴於 JavaScript 引擎對 sort() 的實作（在某些情況下可能不穩定），導致保留與刪除的成品選擇具有不確定性。
建議：建議在排序邏輯中加入次要的排序鍵值（如 id 或 tag_name）作為比較依據（例如：若時間相同，則比較 ID 大小），以確保排序結果在時間相同時仍具有決定性。

**嚴重等級**：🟡 警告 **審查員**：Mage **問題**：在 `selectReleasesToDelete` 的排序邏輯中，若多個成品具有完全相同的 `created_at` 時間戳，目前的排序行為依賴於 JavaScript 引擎對 `sort()` 的實作（在某些情況下可能不穩定），導致保留與刪除的成品選擇具有不確定性。 **建議**：建議在排序邏輯中加入次要的排序鍵值（如 `id` 或 `tag_name`）作為比較依據（例如：若時間相同，則比較 ID 大小），以確保排序結果在時間相同時仍具有決定性。
.sort((a, b) => b.time - a.time) release,
time: createdTime(release),
id: Number(release?.id) || 0,
}))
.sort((a, b) => b.time - a.time || b.id - a.id)
Ghost marked this conversation as resolved
gitea-actions commented 2026-06-26 03:30:27 +00:00
Review
Copy Link
Copy Source

嚴重等級：🔵 建議
審查員：Bard
問題：在 cleanupReleases 函式中，參數 config 是 ReturnType<import('./config.js').loadConfig>，這種型別定義方式雖然準確，但過於冗長且與實作細節耦合過深，影響程式碼的可讀性與簡潔度。
建議：建議在 app/config.js 定義並匯出型別註解（JSDoc @typedef），然後在此處直接使用該別名，提升整體程式碼的可讀性。

**嚴重等級**：🔵 建議 **審查員**：Bard **問題**：在 `cleanupReleases` 函式中，參數 `config` 是 `ReturnType<import('./config.js').loadConfig>`，這種型別定義方式雖然準確，但過於冗長且與實作細節耦合過深，影響程式碼的可讀性與簡潔度。 **建議**：建議在 `app/config.js` 定義並匯出型別註解（JSDoc @typedef），然後在此處直接使用該別名，提升整體程式碼的可讀性。
gitea-actions commented 2026-06-26 03:34:26 +00:00
Review
Copy Link
Copy Source

嚴重等級：🔵 建議
審查員：Bard
問題：config 參數型別定義方式雖然準確，但過於冗長且與實作細節耦合過深，影響程式碼的可讀性與簡潔度。
建議：建議在 app/config.js 定義並匯出型別註解（JSDoc @typedef），然後在各處直接使用該別名。

**嚴重等級**：🔵 建議 **審查員**：Bard **問題**：config 參數型別定義方式雖然準確，但過於冗長且與實作細節耦合過深，影響程式碼的可讀性與簡潔度。 **建議**：建議在 `app/config.js` 定義並匯出型別註解（JSDoc @typedef），然後在各處直接使用該別名。
.map((entry) => entry.release) .map((entry) => entry.release)
.slice(keepCount) .slice(keepCount)
} }
19