41 lines
4.0 KiB
JSON
41 lines
4.0 KiB
JSON
{
|
|
"excluded_findings": [
|
|
{
|
|
"location": "entrypoint.sh:180",
|
|
"title": "fetch_package_versions jq overhead",
|
|
"reason": "在分頁迴圈中每頁都呼叫 `jq 'length'` 和 `jq -s '.[0] + .[1]'`，導致每次啟動新的 jq 程序，產生大量 I/O 與程序啟動開銷，特別是當某個套件有多頁版本時。建議：合併/流式處理 JSON（例如一次合併多頁、或使用 `jq -s`/streaming、或以 Python 等更高效工具處理），減少頻繁啟動外部程式以降低系統負擔。"
|
|
},
|
|
{
|
|
"location": "entrypoint.sh:305",
|
|
"title": "process_candidates N+1 delete requests",
|
|
"reason": "刪除候選版本時對每個版本發出獨立的 DELETE API 請求（N+1 典型案例），若候選數量大會產生大量 API 請求與延遲。呼叫內部也多次對 `owner`、`package_name`、`version` 執行 `url_encode`/`jq`，增加重複開銷。建議：檢查 Gitea 是否支援批次刪除或改為先一次取得所有版本再批次處理；對每個路徑欄位只 URL encode 一次並重用編碼結果；將外部工具呼叫合併或改為更有效的處理方式以降低啟動次數與延遲。"
|
|
},
|
|
{
|
|
"location": "entrypoint.sh",
|
|
"title": "collect_package_candidates N+1 package fetch",
|
|
"reason": "在 `collect_package_candidates` 函數中，目前對 `INPUT_PACKAGE_NAMES` 的每個套件都分別呼叫 `fetch_package_versions`，導致 N+1 查詢與大量 API 請求，當套件數量多時會增加網路延遲與 Gitea 伺服器負載。建議：改為先一次或少次呼叫以取得 owner 下所有 NuGet 套件與其版本（例如用 `/api/v1/packages/${owner}?type=nuget` 或 `fetch_all_pages`），在本地用 `jq group_by(.name)` 或等效邏輯分組並依 `TARGET_PACKAGES` 篩選；如此可大幅減少不必要的 API 請求、網路流量與本地處理負擔，避免 N+1 問題並提升效能與擴展性。"
|
|
}
|
|
,
|
|
{
|
|
"location": "entrypoint.sh:176",
|
|
"title": "collect_package_candidates N+1 (explicit)",
|
|
"reason": "在 collect_package_candidates 函數中，程式碼從原本一次性獲取所有 NuGet 套件資訊（透過 fetch_all_pages 呼叫 /api/v1/packages/${REPO_OWNER}?type=nuget），改為針對 INPUT_PACKAGE_NAMES 中的每個套件名逐一呼叫 fetch_package_versions。若 INPUT_PACKAGE_NAMES 包含大量套件，這會導致大量獨立的 API 請求（N 個套件 * N 頁面），顯著增加網路延遲與 Gitea 伺服器負載，並且可能造成執行時間大幅增加。建議：考慮恢復到原始的資料擷取策略，先一次或少次取得所有套件與版本，然後在本地進行過濾與分組，以減少 API 呼叫數量。"
|
|
},
|
|
{
|
|
"location": "entrypoint.sh",
|
|
"title": "log function definition unclear",
|
|
"reason": "腳本中廣泛使用了 `log` 函式，但此 diff 並未包含 `log` 的定義，表示 `log` 可能來自基礎映像或另一個未包含的腳本。建議：在 entrypoint.sh 明確定義 `log` 或在文件/腳本中註明其來源，提升可維護性與自包含性。"
|
|
},
|
|
{
|
|
"location": "entrypoint.sh:46",
|
|
"title": "resolve_token empty-token test suggestion",
|
|
"reason": "新增測試案例，驗證當 `RUNNER_TOKEN` 和 `INPUT_GITEA_TOKEN` 都為空時，`resolve_token` 函數會正確地失敗並輸出錯誤訊息。建議：加入單元測試覆蓋空 token 的情境，確保函數在無認證資訊時能安全終止並回報清晰錯誤。"
|
|
},
|
|
{
|
|
"location": "entrypoint.sh:91",
|
|
"title": "parse_repo_context invalid-input test suggestion",
|
|
"reason": "新增 `parse_repo_context` 的測試案例，驗證在以下無效輸入時會正確失敗：空字串或僅含空白字元、不含斜線的字串、包含多個斜線的字串、只有斜線的字串、只有 owner 或只有 repo 的字串。建議：為上述邊界與無效格式情境撰寫單元測試，以驗證解析函數的健壯性並確保在錯誤輸入時有明確行為。"
|
|
}
|
|
]
|
|
}
|