Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Proposal: run SmartOS and AIX in node-daily-master instead of node-test-pull-request

オープン
#4,457 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
38/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
node.js

調査の方向性

まず Jenkins ジョブの node-test-pull-request と node-test-commit から始め、次に Tier 2 の要件について node-daily-master と BUILDING.md を確認します。ここで説明されている parameter と separate-multijob のオプション(SmartOS 専用のバリエーションを含む)を比較し、executor-deadlock のコンテキストについて #4435 を確認します。合意された CI 設定によって SmartOS と AIX を daily CI と release CI に残しつつ、PR gate から除外できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

platform:aix platform:smartos

I pulled a month of node-test-pull-request history out of the Jenkins API (450 runs across 167 PRs, 2026-08-06 to 2026-09-05) to see where PR CI time goes. Most of it is waiting for an executor on two platforms rather than running tests, so i'd like to propose running SmartOS and AIX from node-daily-master only and dropping them from the PR job.

job runs median p90 of which waiting for an executor (median / p90) slowest configuration's own run (median)
node-test-commit-smartos 362 246 min 453 min ~215 / ~409 min 46 min (smartos23-x64)
node-test-commit-aix 407 152 min 334 min ~87 / ~261 min 69 min (aix73-power9)
node-test-commit-linux (10 configs) 421 94 min 305 min ~22 / ~194 min 62 min (rhel8-x64)
node-test-commit-osx 433 91 min 188 min ~5 / ~105 min 65 min (macos15-x64)
node-test-commit-linux-containered 435 66 min 154 min ~17 / ~91 min 43 min
node-test-commit-windows-fanned 428 58 min 192 min
node-test-commit-arm 431 52 min 112 min ~0 / ~12 min 45 min (rhel8-arm64)
node-test-commit-plinux 442 35 min 69 min ~0 / ~22 min 33 min
node-test-commit-linuxone 447 30 min 51 min ~0 / ~6 min 30 min
node-test-linter 445 15 min 20 min
node-test-pull-request, end to end 437 245 min 577 min

"Waiting for an executor" is the matrix job's duration minus its slowest configuration's execution time (the API doesn't expose queue time for matrix children directly); aborted runs are excluded. Over the same window 13% of PR runs finished SUCCESS and another 18% UNSTABLE, the average PR needed 2.7 runs, and when exactly one child job was non-green in a run it was linuxone 34 times (nearly all yellow from marked-flaky tests), aix 19, osx 17, linux 17, windows 9, smartos 4. Raw per-configuration numbers (exec median/p90, failure rate) are available if useful.

What the change would mean in practice: SmartOS and AIX stay Tier 2 exactly as BUILDING.md defines it (full test coverage maintained, failures block releases), keep running in node-daily-master and release CI, and failures there get filed the way other daily-only jobs are handled. PRs stop holding a jenkins-workspace executor for 2-3 h while a single smartos23 executor works through the queue, which by these numbers moves the median PR run from ~4 h to ~1.5 h (osx/linux become the long pole) with no new hardware, and takes some pressure off the executor deadlocks discussed in #4435. ppc64le and s390x are also Tier 2 but have no queueing to speak of, so i'd leave them in the PR job.

Mechanically i think this is either a parameter on node-test-commit that node-test-pull-request sets to skip those two phases, or a second multijob without them for the PR trigger; whichever the WG prefers. Two questions before this goes on an agenda: is there history on why these two gate PRs specifically rather than the daily, and would anyone want a lighter variant first (e.g. keep AIX and move only SmartOS, which is the larger share of the wait)?

Refs: #4435
Refs: https://github.com/nodejs/node/pull/65826 (separate, cuts console log volume from the same jobs)

主要言語
Jinja
スター
541
フォーク
185
平均マージ
2日 18時間
マージ済み PR(30日)
6

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nodejs/build のほかの issue

nodejs/build の issue をすべて見る

似ている issue

Build System の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。