Repository navigation
PR の pytest が 1 回 10〜13 分かかり、push のたびに古い実行も止まらず走り直す #2154
Description
目標
PR の pytest（Python tests ワークフロー）の所要時間を 3 分以内にする（利用者の指定。2026-10-28）。測るのは、ワークフローの開始から必須のチェック pytest の結果が付くまでの時間で、今は 10〜13 分かかっている。
何を見つけたか
PR の Python tests ワークフローの pytest が 1 回 10〜13 分かかり、マージ待ちが長くなる。さらに、待っている間に PR へ push すると CI が最初から走り直し、古い実行も止まらずに最後まで走る。
PR #2153（feature/chrome-cdp）での実測（UTC）:
| 実行 | head | pytest (0/2) | pytest (1/2) |
|---|---|---|---|
| 40486032958 | a866e23 | 10:07:36 → 10:16:59（9 分 23 秒） | 10:07:36 → 10:18:38（11 分 2 秒） |
| 40528036010 | 5d5aa5f | 15:08:54 → 15:20:27（11 分 33 秒） | 15:08:53 → 15:19:41（10 分 48 秒） |
| 40666119346 | 832b623 | 09:40:59 → 09:53:28（12 分 29 秒） | 09:40:59 → 09:53:55（12 分 56 秒） |
| 40666810233 | 6f07253 | 09:46:13 → 実行中 | 09:46:13 → 実行中 |
| 40666976000 | 2ddffd9 | 09:47:30 → 実行中 | 09:47:29 → 実行中 |
- テストは約 10,400 件（PR Add: 利用者の Chrome を開発コンテナから CDP で操作する Skill chrome-cdp を足す #2153 の手元の実行で 10412 passed）。
ubuntu-latestの 2 ジョブに分け、各ジョブの中を-n autoで回している（.github/workflows/pytest.yml:58-89） - 2026-10-28 は 09:45 と 09:47 に PR へ push があり、09:53 に通った実行の結果は使われず、2 本の実行が同時に走った。09:46 の実行は先端でなくなった後も走り続け、runner を取り合う
pytest.ymlにconcurrency（cancel-in-progress）の設定が無い
どこで見つけたか
- PR Add: 利用者の Chrome を開発コンテナから CDP で操作する Skill chrome-cdp を足す #2153 を
merged-steps.py merge-when-greenでマージ待ちしている間（2026-10-28） .github/workflows/pytest.yml:56-89（2 分割の matrix と-n auto）
なぜこの変更の範囲外なのか
PR #2153 の範囲は chrome-cdp の Skill の追加と playwright-kit の整理で、CI の構成は受け入れ条件にも直す対象にも入らない。利用者はこの PR のマージと配布を求めており、CI の構成を変えると配布の差分が増える。根拠: 共通原則の「判断の範囲は目の前の変更・操作に限る」（MVV なし）。
直さないと何が起きるか
- PR 1 本のマージ待ちが毎回 10 分以上になる。スプリントの PR・リリースの PR（release/v → develop）・develop → main の PR と続くため、1 回の配布で待ちが積み上がる（リリースの PR は pytest を省くが、スプリント内の各 PR は省かない）
- 待ちの途中で push すると、さらにもう 1 回分（10 分以上）待つ。古い実行が runner を使い続け、同時に走る他の PR の CI も遅れる
対策の候補（どれを採るかは設計で決める。目標の 3 分に届くかを実測で確かめる）:
pytest.ymlにconcurrency: { group: <ワークフロー>-<PR か ref>, cancel-in-progress: true }を足し、同じ PR の古い実行を止める。必須のチェックpytestの集約ジョブへの影響（取り消された実行の結果の扱い）を確かめる- 分割数を 2 から増やす（例: 4）。runner の起動と依存の導入の時間との釣り合いを実測で決める
--durationsで遅いテストを洗い出し、上位を速くするか、変更範囲に応じて省けるかを見る（pytest-scopeの絞り込みとの関係を含む）- 依存の導入（
uv）のキャッシュが効いているかを確かめる
起票者の推定
- 対策の候補 1〜4 は起票者が挙げたもの。利用者の指示は「CI が遅い件とその対策」で、具体策は指定していない（推した出所: 会話、
.github/workflows/pytest.yml） - 「runner を取り合う」「他の PR の CI も遅れる」は、同時に 2 本の実行が走った観測からの推定で、待ち時間への影響は測っていない（推した出所:
gh run list -b feature/chrome-cdp -w "Python tests"の結果） - 1 回の配布で待ちが積み上がる、という影響の見積もりは
release-steps.py releaseの流れからの推定（推した出所:plugins/ndf/scripts/release-steps.py:651-760）
由来
PR #2153
Activity