Background
最近の CI 失敗には、packages/ztd-cli 内の決定論的なコード不具合が、後段の重い consumer/package verification job まで進んでから重複して表面化するケースがありました。
この種の失敗は flaky ではなく、ztd-cli 自体の build を先に通せば早い段階で止められる性質のものです。
Problem
現在は、ztd-cli を触る変更でも、package-local な compile/build failure が consumer guard や packaging verification の前段で十分に fail-fast になっていない可能性があります。
その結果、同じ根本原因で複数 job が落ち、CI の読み解きと修正の往復が重くなります。
Proposal
packages/ztd-cli に影響する PR では、consumer/package verification より前に package-local build を必須 gate として実行したいです。
最低限、以下を前段で確実に通す方針を取りたいです。
pnpm --filter @rawsql-ts/ztd-cli run build
必要に応じて、どの変更を対象にするかは path 条件で絞りますが、まずは「ztd-cli の明確な build failure を重い後段 job に持ち込まない」ことを優先したいです。
Expected benefit
- 決定論的な product bug を早い段階で止められる
- consumer/package verification の無駄な失敗を減らせる
- CI failure の根因が読みやすくなる
- 修正サイクルを短くできる
Definition of done
packages/ztd-cli を触る PR で package-local build が前段の必須 gate として実行される- 当該 gate の失敗時は consumer/package verification job に進まない
- どの変更が gate 対象になるかが CI 設定または docs で明文化される
Background
最近の CI 失敗には、
packages/ztd-cli内の決定論的なコード不具合が、後段の重い consumer/package verification job まで進んでから重複して表面化するケースがありました。この種の失敗は flaky ではなく、
ztd-cli自体の build を先に通せば早い段階で止められる性質のものです。Problem
現在は、
ztd-cliを触る変更でも、package-local な compile/build failure が consumer guard や packaging verification の前段で十分に fail-fast になっていない可能性があります。その結果、同じ根本原因で複数 job が落ち、CI の読み解きと修正の往復が重くなります。
Proposal
packages/ztd-cliに影響する PR では、consumer/package verification より前に package-local build を必須 gate として実行したいです。最低限、以下を前段で確実に通す方針を取りたいです。
pnpm --filter @rawsql-ts/ztd-cli run build必要に応じて、どの変更を対象にするかは path 条件で絞りますが、まずは「
ztd-cliの明確な build failure を重い後段 job に持ち込まない」ことを優先したいです。Expected benefit
Definition of done
packages/ztd-cliを触る PR で package-local build が前段の必須 gate として実行される