ci(e2e): 実測で組を割り直し、長いスペック2本を分ける

.github/workflows/test.yml

@@ -32,8 +32,8 @@ permissions:
 # 合わせても1分ありません。待っているのは**いちばん遅い1つ**だけでよいので、
 # 中身の関係ないものを、それぞれ別のランナーに出しています。
 #
-# E2E はさらに5つに割ります (組分けは tests/e2e/shards.json)。ランナーは4コアで
-# 1台3ワーカー (playwright.config.ts) なので、5台で15ワーカーぶん並びます
+# E2E はさらに6つに割ります (組分けは tests/e2e/shards.json)。ランナーは4コアで
+# 1台3ワーカー (playwright.config.ts) なので、6台で18ワーカーぶん並びます
 # (中身は待ち時間が大半なので、割った分だけ効く。
 # docs/development.md「並べて流す」)。
 jobs:
@@ -531,7 +531,7 @@ jobs:
         # 同じ組に固まり、28秒の組と3.6分の組ができていた
         # **組を増やしたら、main の ruleset の必須チェックにも `e2e (n)` を足すこと** (足さないと
         # 増やした組が落ちていてもマージできてしまう。bump の PR は ruleset から引くので直さなくてよい)
-        shard: [1, 2, 3, 4, 5]
+        shard: [1, 2, 3, 4, 5, 6]
     steps:
       - name: Checkout
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
@@ -592,7 +592,7 @@ jobs:
         run: |
           ls tests/e2e/*.spec.ts | xargs -n1 basename | sed 's/\.spec\.ts$//' | sort > "$RUNNER_TEMP/all"
           jq -r 'del(."//") | .[][]' tests/e2e/shards.json | sort > "$RUNNER_TEMP/listed"
-          jq -e 'del(."//") | keys == ["1","2","3","4","5"]' tests/e2e/shards.json > /dev/null
+          jq -e 'del(."//") | keys == ["1","2","3","4","5","6"]' tests/e2e/shards.json > /dev/null
           dup=$(uniq -d "$RUNNER_TEMP/listed")
           if [ -n "$dup" ]; then echo "::error::2つの組に入っています: $(echo $dup)"; exit 1; fi
           gone=$(comm -13 "$RUNNER_TEMP/all" "$RUNNER_TEMP/listed")

docs/development.md

@@ -86,11 +86,16 @@ PR を出して自分でマージします。急ぐときは Actions から手
 **1台ではこれ以上縮みません。** 中身の合計は約3分で大半は偽の放送を待つ時間、
 下限はいちばん長いファイル1本の時間です。
 
-CI では5つに割って別のランナーに出し、3ワーカー×5台 = 15ワーカーぶん並べます。
+CI では6つに割って別のランナーに出し、3ワーカー×6台 = 18ワーカーぶん並べます。
 組の中身は `tests/e2e/shards.json` で、実測の所要時間 (CI の結果に出る1本ずつの秒数) で人が割っています。
 組ごとにテストの秒数の和がそろうように割り、長いファイルは組の頭のほうに来るように組みます
 (組の中ではファイル名の順にワーカーへ配られるので、遅れて始まらずに済む)。組の時間の下限は、その組でいちばん長いファイル1本です。
 
+- 映像を長くデコードし続けるスペック (20-live・22-watch・互換モードのものなど。一覧は shards.json の注記) は1つの組に寄せすぎません。混むとどれも遅くなります
+- 50-live-pacing は 6 組に1本だけで置きます。貯める量は狙い (0.2 秒) の 1.5 倍を超えるまで詰めない作りなので、再生を始めた瞬間に組の中が混んでいて
+  多めに貯まると、そのまま 0.26 秒あたりで落ち着き、テストの上限 0.25 秒を超えます。1本だけで流すと冷えたワーカーでも 0.18〜0.19 秒でした
+- 1本で1分を超えるスペックは、組の時間の下限を押し上げるので分けます (57-jikkyo-recorded はそうして分けたもの)。
+  26-hwenc はまだ分けていません (一番長い 170 秒。軽いスペックの組に置いている)
 - どの組にも入れていない新しいスペックは **5 組で流れます** (CI に注記が出る)。あとで所要時間を見て割り直してください
 - shards.json にあるのにファイルが無い・2つの組に入っている、は CI の「組分けの検算」が落とします
 - 組を増やしたら、test.yml の `shard` の並びと検算の組の名前、main の ruleset の必須チェックにも `e2e (n)` を足します
@@ -186,7 +191,7 @@ JSON で持つ列 (ジャンル・音声の構成・ルールの対象の局な
 
 `Dockerfile` が denpa 本体、`agent/Dockerfile` がチューナー側です。
 CI が両方をビルドして `deploy/` の印を書き戻します。**main は直接 push できない**
-(ruleset の必須チェック `check` / `agent` / `e2e (1)`〜`(5)` / `claude-review`) ので、
+(ruleset の必須チェック `check` / `agent` / `e2e (1)`〜`(6)` / `claude-review`) ので、
 書き戻しは bot が PR を出し、必須チェックの status を自分で付けてマージします
 (手順と理由は `.github/bump-pr.sh`。release の Chart.yaml の書き戻しと README の謝辞の一覧も同じ)。
 release は組み直さず、main で組んだイメージにバージョンを 1 層足します

tests/e2e/26-hwenc.spec.ts

@@ -268,9 +268,16 @@ test.describe("GPU でエンコードする", () => {
     );
     await waitWatchable(page, row);
     let recordingId = await row.getAttribute("data-recording-id");
-    const ways = encodeRuns(stack.encodeArgsFile, recordingId).map(wayOf);
-    expect(ways).toHaveLength(3);
-    expect(ways[0]).toMatch(/^renderD128:hevc_vaapi$/);
+    const runs = encodeRuns(stack.encodeArgsFile, recordingId);
+    expect(runs).toHaveLength(3);
+    /*
+     * 1本目は CM 検出の材料を一緒に取るもの (書き出しを `denpa-scan-…` に置く)。**引数を書いた順では見ない** —
+     * 3本は同時に立ち上がるので、どれが先に書くかは決まらない (CI で AV1 が先に来て落ちていた)
+     */
+    const lead = runs.filter((run) =>
+      run.some((a) => a.includes("denpa-scan-")),
+    );
+    expect(lead.map(wayOf)).toEqual(["renderD128:hevc_vaapi"]);
     const main = (await row.getAttribute("data-library-path")) ?? "";
     expect(main).toMatch(/\.mkv$/);
     expect(main).not.toMatch(/\[H26[45]\]/);