run: --phases does not suppress the UI-label test phase (determinePhasesForIssue adds it to an explicit list)

クローズ 初心者向け
  • 何か問題がありますか？
#1,631 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #1659 @admarble による — マージ済み

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
cli

調査の方向性

バグは src/lib/workflow/phase-mapper.ts の determinePhasesForIssue にあります。その末尾のブロックは、hasUILabels(labels) が真であれば、明示的な --phases リストが指定されていても test を追加します。batch-executor.ts の runIssueWithLogging の明示的な分岐からの呼び出しを追跡し、config-resolver.ts で autoDetectPhases がどのように設定されているかを確認してください。フロントエンドのラベルが付いた issue に対して --phases spec を実行したときにテストフェーズが実行されず、--testgen と --security-review は引き続きそれぞれのフェーズを追加すれば完了です。

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

説明

What happens

sequant run 930 --phases spec ran a test phase after spec. The cause is not the spec marker (first guess, corrected after reading the code): determinePhasesForIssue in src/lib/workflow/phase-mapper.ts appends test whenever hasUILabels(labels) is true, and it runs on the explicit --phases list too. #930 carries the frontend label; the other three issues in the batch do not and ran spec only.

Evidence (sequant 2.20.0, admarble/matcha-maps)

Run header:

Phases         spec
Mode           parallel (concurrency: 1)
Issues         #1101, #1019, #929, #930

For #930 only (labels: frontend, planned, performance):

[23:34:14] ✔ #930 spec 55s
[23:34:14] ▸ #930 test
...
**Summary:** 0/1 tests passed. AC-7, the only browser test, is BLOCKED because the feature isn't implemented on this branch.
[23:34:47] ✔ #930 test 33s
  #930    ✔ passed   spec → test

Code path (dist 2.20.0): config-resolver.ts sets autoDetectPhases = !cliOptions.phases && settings.run.autoDetectPhases, so label detection is correctly off. But batch-executor.ts runIssueWithLogging then takes the explicit branch, "Use explicit phases with adjustments", and calls determinePhasesForIssue(config.phases, labels, options), whose last block is:

// Auto-detect UI issues and add test phase
if (hasUILabels(labels) && !phases.includes("test")) { ... phases.push("test"); }

That block ignores whether the phase list was explicit. The same function also honours --testgen and --security-review, which are flags the user passed, so those two adjustments are expected; the label one is not.

Why it matters

A coordinator that runs spec batches to compare file lists before picking a wave expects spec-only cost and no implementation-side phases. Here the extra phase was cheap (33 s, a blocked result) but it posted test output against an unimplemented branch and would have run a browser test had one been possible. The earlier label case (an unrequested test phase on #857 in a spec-only batch) was the same block; passing --phases explicitly was adopted as the workaround and does not work for this path.

Ask

In determinePhasesForIssue, skip the UI-label test insertion when the phase list came from --phases (for example, pass options.autoDetectPhases or an explicit flag and gate the block on it), or move that block into detectPhasesFromLabels where the other label logic lives. A Phases adjusted: log line is printed today, so the behaviour is visible, but a user who wrote --phases spec did not ask for test.

主要言語
TypeScript
スター
1
フォーク
1
平均マージ
10時間 59分
マージ済み PR（30日）
86

環境構築

はじめの一歩

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

sequant-io/sequant のほかの issue

sequant-io/sequant の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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