chore: update ai-review findings [ai-review-bot][failure]

.gitea/ai-review/findings.json

@@ -1,23 +1,16 @@
 [
   {
     "level": "critical",
-    "role": "Aria",
-    "location": "entrypoint.sh",
-    "suggestion": "檔案結尾缺少一個換行符號。根據 POSIX 規範，所有文字檔案都應以換行符號結束。請在檔案的最後一行後新增一個換行符號。",
+    "role": "Leo",
+    "location": "entrypoint.sh:98-142",
+    "suggestion": "在 `calculate_version` 函式中，`jq` 腳本的邏輯過於複雜且龐大。它重新實作了 `latest_stable_version`、`next_release_version` 和 `next_beta_number` 等函式中的邏輯。這種跨語言（Bash 與 jq）的邏輯重複會大幅增加維護難度與錯誤風險。建議將 `calculate_version` 函式重構為呼叫這些已存在的 Bash 輔助函式，以簡化 `jq` 的職責，使其僅用於資料提取而非複雜的邏輯運算。如果必須使用單一 `jq` 腳本，請考慮將其拆分為多行並使用 `read -r -d '' JQ_SCRIPT << 'EOF'` 語法，以提高可讀性。",
     "is_new": true
   },
   {
     "level": "critical",
-    "role": "Maya",
-    "location": "entrypoint.sh",
-    "suggestion": "此腳本包含複雜的邏輯，特別是版本解析與遞增，並依賴外部服務（如 `curl` 和 `jq`）。目前完全沒有提供任何測試，這使得任何修改都存在高風險。請務必實作一套健全的測試套件，例如使用 `bats` 或 `shunit2` 等 shell 測試框架。測試應包含單元測試（針對輔助函數）和整合測試（模擬外部依賴，如 `curl` 和 `jq` 的回應），以涵蓋各種情境（例如不同的發布歷史、網路錯誤、格式錯誤的 JSON）。",
-    "is_new": true
-  },
-  {
-    "level": "critical",
-    "role": "Maya",
-    "location": "entrypoint.sh:86-91",
-    "suggestion": "版本號遞增邏輯中，當 `PATCH` 達到 `10` 時會遞增 `MINOR`，當 `MINOR` 達到 `10` 時會遞增 `MAJOR`。這與標準的語義化版本控制（Semantic Versioning）慣例不同（例如，通常 `1.9.9` 之後是 `1.9.10`，而非 `2.0.0`）。請釐清預期的版本控制方案。如果目標是標準語義化版本，則應移除 `MINOR` 和 `MAJOR` 在 `10` 時的進位邏輯。如果這是一個自訂的十進位版本系統，請務必清楚文件化此行為，並新增特定測試案例，例如 `v0.0.9`、`v0.9.9`、`v0.9.0`、`v1.9.9`，以驗證進位行為是否符合預期。",
+    "role": "Leo",
+    "location": "tests/entrypoint_test.sh:50-109",
+    "suggestion": "在 `make_mock_jq` 函式中，為了測試 `entrypoint.sh`，您在 Python 中重新實作了核心的版本計算邏輯。這導致了業務邏輯的嚴重重複（Python 與 `entrypoint.sh` 中的 `jq` 腳本），使得測試本身變得複雜且脆弱。如果 `entrypoint.sh` 中的版本計算邏輯發生變化，此 Mock 也需要同步更新，這極易引入錯誤。建議簡化 `entrypoint.sh` 中的 `jq` 邏輯（如前一個建議所述），這樣 Mock `jq` 就可以更簡單，例如僅根據輸入返回預定義的輸出，而不是重新計算邏輯。",
     "is_new": true
   },
   {
@@ -25,34 +18,34 @@
     "role": "Zara",
     "location": "entrypoint.sh:65, entrypoint.sh:90",
     "suggestion": "腳本多次對完整的 `RELEASE_JSON` 字串執行 `jq` 命令來提取不同資訊。儘管 `RELEASE_JSON` 已載入記憶體，但每次 `jq` 呼叫都會啟動新程序並重新解析字串。對於擁有大量發行版本的儲存庫，這可能導致顯著的效能開銷。建議考慮將這些 `jq` 操作合併為單次處理，以一次性提取所有所需資料（最新的穩定版本和計算出的新版本最高 beta 編號），從而減少 CPU 週期和程序啟動的開銷。",
-    "is_new": true
+    "is_new": false
   },
   {
     "level": "warning",
-    "role": "Rex",
-    "location": "entrypoint.sh:42, entrypoint.sh:43, entrypoint.sh:55",
-    "suggestion": "GITEA_SERVER_URL 和 GITEA_REPOSITORY 變數直接用於構建 URL。雖然在 CI/CD 環境中這些變數通常被視為受信任的輸入，但若這些輸入來源不可信，可能導致伺服器端請求偽造 (SSRF) 或路徑遍歷攻擊。建議對這些變數進行更嚴格的輸入驗證，例如檢查 URL 是否符合預期的格式和網域，並確保儲存庫名稱不包含惡意字元（如 `../` 或特殊編碼字元）。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Aria",
-    "location": "entrypoint.sh:44",
-    "suggestion": "`require_env` 函數中的 `printf '%s=%s\n' \"$name\" \"$value\"` 會直接印出環境變數的值。對於 `RUNNER_TOKEN` 這類敏感資訊，這可能導致安全風險。建議修改此函數，使其僅印出變數名稱，或對敏感變數的值進行遮蔽處理。例如，可以改為 `info \"$name 已設定\"`，或在呼叫 `require_env` 之前處理敏感變數的輸出。",
+    "role": "Leo",
+    "location": "entrypoint.sh:159",
+    "suggestion": "在 `main` 函式中，`curl -fsS` 會抑制所有進度與錯誤訊息。雖然 `set -e` 會在 `curl` 失敗時終止腳本，但缺乏詳細的錯誤輸出會使問題診斷變得困難。建議在 `curl` 失敗時，能將其錯誤訊息導向到標準錯誤輸出，或在 `fail` 函式中提供更具體的錯誤上下文，例如 `RELEASE_JSON=\"$(curl -fsS -H ... \"$RELEASE_URL\" || fail \"無法從 Gitea 伺服器取得 Release 資訊\")\"`。",
     "is_new": true
   },
   {
     "level": "warning",
     "role": "Maya",
-    "location": "entrypoint.sh:70-73",
-    "suggestion": "用於提取 `LATEST_VERSION` 和 `BETA` 的 `jq` 指令相當複雜，且依賴特定的 JSON 結構。儘管 `curl -fsS` 有助於處理網路錯誤，但 `jq` 在面對格式錯誤或邊界條件的 JSON 回應時，仍可能產生非預期的結果。請新增專門的測試案例，為 `jq` 提供各種模擬的 `RELEASE_JSON` 輸入，包括：空的發布陣列 `[]`、僅包含 beta 版本的陣列、沒有任何發布的陣列（例如 `curl` 返回 `null` 或空字串）、具有非標準 `tag_name` 格式的發布，以及格式錯誤的 JSON。",
+    "location": "tests/entrypoint_test.sh:L209",
+    "suggestion": "在 `test_unit_helpers` 中，`next_release_version` 函數的測試案例涵蓋了 patch 和 minor 版本的進位，但缺少對 major 版本進位的測試 (例如，從 '9.9.9' 進位到 '10.0.0')。請添加此邊界條件的測試，以確保版本號計算的完整性。",
     "is_new": true
   },
   {
     "level": "warning",
     "role": "Maya",
-    "location": "entrypoint.sh:54-57",
-    "suggestion": "`IS_BETA` 變數的初始化邏輯 (`IS_BETA=\"${IS_BETA:-false}\"` 接著 `if [ \"$IS_BETA\" = \"null\" ] || [ -z \"$IS_BETA\" ]; then IS_BETA=\"false\"; fi`) 略顯冗餘。如果 `IS_BETA` 確實是字串 \"null\"，則第一個賦值不會改變它，而第二個 `if` 條件會處理。如果 `IS_BETA` 未設定或為空，第一個賦值會將其設為 \"false\"，使得 `if` 條件中的 `[ -z \"$IS_BETA\" ]` 為假。請簡化 `IS_BETA` 的初始化邏輯，以提高清晰度和穩健性。例如，可以考慮使用 `IS_BETA=$(echo \"${IS_BETA:-false}\" | sed 's/null/false/')` 或更清晰的條件區塊。同時，請新增測試案例，涵蓋 `IS_BETA` 未設定、空字串、字串 \"null\"、\"true\"、\"false\" 以及其他非預期字串值的情況，以確保行為一致。",
+    "location": "tests/entrypoint_test.sh:L209",
+    "suggestion": "目前測試案例中，雖然 `run_entrypoint` 函數接受 `token` 參數，但沒有明確的測試案例來驗證當 `RUNNER_TOKEN` 存在時，`curl` 是否正確地使用了授權標頭。請添加一個測試案例，明確地傳遞 `RUNNER_TOKEN` 並驗證其行為。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Maya",
+    "location": "tests/entrypoint_test.sh:L209",
+    "suggestion": "測試腳本在執行過程中會創建臨時文件和目錄（例如 `response_file` 和 `workdir`），但目前沒有明確的清理機制來移除這些臨時資源。這可能導致測試環境中累積不必要的檔案。建議在測試腳本的開頭或結尾添加 `trap 'rm -rf \"$workdir\" \"$response_file\"' EXIT` 等清理命令，確保測試完成後所有臨時資源都被妥善移除。",
     "is_new": true
   },
   {
@@ -60,41 +53,20 @@
     "role": "Zara",
     "location": "entrypoint.sh:58",
     "suggestion": "腳本從 Gitea API 獲取所有發行版本。如果儲存庫中的發行版本數量非常龐大，這可能會消耗大量的網路頻寬和記憶體。儘管目前的邏輯可能需要檢查多個發行版本（例如，尋找最新的穩定版或特定的 beta 版本），但值得研究 Gitea API 是否提供更精細的過濾（例如，按標籤名稱模式或排除 beta 標籤）或分頁功能，以減少獲取的資料量，特別是當腳本只需要部分發行版本資訊時。",
-    "is_new": true
+    "is_new": false
   },
   {
     "level": "info",
-    "role": "Rex",
-    "location": "entrypoint.sh:109",
-    "suggestion": "將 NEW_VERSION 輸出到 GITHUB_OUTPUT 時，雖然目前 NEW_VERSION 的格式（如 `X.Y.Z` 或 `X.Y.Z-beta.N`）相對安全，不太可能包含換行符或其他特殊字元，但一般而言，應確保輸出到環境變數或檔案的內容不包含可能導致指令注入的特殊字元。對於複雜或多行內容，應使用 GitHub Actions 建議的多行輸出語法以確保安全。",
+    "role": "Leo",
+    "location": "entrypoint.sh:110",
+    "suggestion": "在 `calculate_version` 函式內的 `jq` 腳本中，版本號進位邏輯使用了「10」這個魔術數字（例如，`patch >= 10`）。雖然這是常見的版本控制慣例，但為了提高程式碼的清晰度和未來可配置性，建議將其定義為一個具名的 `jq` 變數或 Bash `readonly` 常數。",
     "is_new": true
   },
   {
     "level": "info",
     "role": "Aria",
-    "location": "entrypoint.sh:5",
-    "suggestion": "在 `readonly` 變數定義和第一個函數定義之間增加一個空行，可以提高程式碼區塊之間的視覺分隔，增強可讀性。",
-    "is_new": true
-  },
-  {
-    "level": "info",
-    "role": "Aria",
-    "location": "entrypoint.sh:53",
-    "suggestion": "為了保持日誌輸出的一致性，建議將 `RUNNER_TOKEN` 的狀態輸出也透過 `info` 函數處理，例如 `info \"RUNNER_TOKEN=***\"` 或 `info \"RUNNER_TOKEN=未提供\"`。這有助於統一日誌格式。",
-    "is_new": true
-  },
-  {
-    "level": "info",
-    "role": "Aria",
-    "location": "entrypoint.sh:70",
-    "suggestion": "多行 `jq` 查詢字串的縮排方式可以考慮調整。為了提高可讀性，可以將 `jq` 腳本內容使用 heredoc 語法，或將其縮排與 `jq -r` 對齊，而不是與 `printf` 的內容對齊。目前的縮排方式雖然功能上無誤，但可能在視覺上造成混淆。",
-    "is_new": true
-  },
-  {
-    "level": "info",
-    "role": "Maya",
-    "location": "entrypoint.sh:109",
-    "suggestion": "此腳本直接寫入 `$GITHUB_OUTPUT`，這是 GitHub Actions 環境特有的行為。雖然這對於其預期用途是正確的，但這使得在沒有完整 GitHub Actions 環境的情況下，難以獨立測試輸出機制。在建立測試套件時，請確保 `write_output` 函數可以透過將 `$GITHUB_OUTPUT` 重定向到臨時文件，或透過模擬 `write_output` 函數本身來進行測試，以便在不執行完整 GitHub Actions 的情況下驗證生成的輸出。",
+    "location": "b/entrypoint.sh:176,182",
+    "suggestion": "在 `main` 函數中，`LATEST_TAG` 和 `NEW_VERSION` 的空值或 `null` 檢查可能是多餘的。`calculate_version` 函數已經處理了這些情況並返回了預設值。建議移除這些檢查以簡化程式碼，除非有特殊情況需要再次驗證 `calculate_version` 的輸出。",
     "is_new": true
   }
 ]