Outdated node-addon-api CI matrix consumes shared runner capacity

未關閉
#4,554 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
45/100
Issue 類型
重構
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
github, javascript, node.js

研究方向

Start with the linked parent and child CI jobs and inspect their matrix configuration, version choices, and defaults, then check how the Node.js release schedule is represented in the linked schedule.json. Trace how the child job's Node 24 override selects nightly builds and find the existing validation entry point. Done means the matrix follows supported LTS lines, each phase has an explicit version, choices stay aligned, and validation catches missing supported lines and retained EOL lines.

由索引模型根據 Issue 內容生成。

描述

The daily node-test-node-addon-api-LTS versions job still runs platform matrices for Node.js 18, 20, 22, and 25. The phase labelled “Test main” inherits the child job's default of 25, as confirmed in this build.

18, 20, and 25 are all EOL, so three of the four phases target unsupported release lines, while supported LTS lines 24 and 26 are missing. Release schedule

Each phase schedules work across shared Linux, macOS, Windows, and AIX workers. The stale matrix therefore creates avoidable demand for runner capacity used by other CI jobs. The job tests node-addon-api main, which now requires Node.js 22 or newer.

The jobs need updating to:

  • Cover 22, 24, and 26, removing the EOL phases.
  • Set an explicit Node.js version for each phase and correct the misleading “Test main” phase.
  • Refresh the child job's version choices/default and remove its stale Node 24 override, which still downloads v24.0.0-nightly builds.
  • Follow the release schedule automatically, adding new LTS lines and dropping EOL lines. Keep the child job's version choices aligned, and add validation that flags missing supported versions or retained EOL versions so this does not depend on annual manual updates.

Related: #4193.

主要語言
Jinja
星號
543
分支
184
平均合併
4 天 7 小時
30 天內合併 PR
7

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

nodejs/build 的其他 Issue

查看 nodejs/build 的全部 Issue

相似的 Issue

更多 DevOps Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。