ci: register the two unclassified perry-codegen suites (unblocks e2e-scoped on every PR) - #10723
Conversation
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review. 📝 WalkthroughWalkthroughThe CI scope script now classifies ChangesCodegen E2E mapping
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix · Severity of issue fixed: Medium 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
`e2e-scoped` has been red on every PR since merge train 218 (v0.5.1596),
failing at "Compute e2e suite scope" in ~16s:
ci_e2e_scope: these crates/perry-codegen/tests/*.rs suites are in neither
SOURCE_SUITE_MAP nor SUITE_EXCLUSIONS: error_subclass_field_init,
typed_collection_receiver_guard
Both suites arrived in 6925754 (#10443/#10446, train 218) and nobody
classified them, which is exactly the condition #7708 added this assertion
for. The failure is content-independent, so it reddens PRs that cannot
possibly have caused it -- #10721 (a Python script) and #10722 (a .ts
fixture) both carry it.
Mapped rather than excluded: both are cheap in-process suites of the shape
SOURCE_SUITE_MAP exists for, and both passed when train 218 ran them as
diff-named suites (2 and 3 tests, 0.01s each). Excluding them would have
hidden working coverage; SUITE_EXCLUSIONS is for a named failing test with
an issue number, which neither has.
Verified discriminating, not merely present: with either entry deleted
`--self-test` exits 1 naming the suite, and exits 0 with both.
2a73bc7 to
bd49ad4
Compare
e2e-scopedhas been red on every PR since merge train 218 (v0.5.1596), failing at "Compute e2e suite scope" after ~16 seconds:The assertion is doing its job — two suites arrived in
6925754a7d(#10443/#10446, train 218) and nobody classified them. This just classifies them.Why this is worth landing ahead of the queue
The failure is content-independent, so it reddens PRs that cannot possibly have caused it. Right now #10721 (a Python script), #10722 (a
.tsfixture) and #10719 (a Python script) all carry it. That is the third standing red onmain, alongside the two in #10707 — and the cost is not the red itself, it is that "CI is red, but it's red for everyone" becomes the default reading and the next genuinely broken PR looks identical.Mapped, not excluded
SUITE_EXCLUSIONSis for a suite held out with a named failing test and an issue number. Neither of these has one — both pass. Excluding them would have hidden working coverage, which is the failure mode #7708 exists to prevent.Both are the cheap in-process shape
SOURCE_SUITE_MAPwas built for, and both ran green when train 218 executed them as diff-named suites:Verification
Not just "the check now passes" — the check still fails when it should:
--self-testrc=0—ci_e2e_scope self-test: okerror_subclass_field_initdeletedrc=1— names the suiterc=0A check that cannot go red is not a check, so the deletion arm is the part that matters.
Fixes the third of the three standing
mainreds; the other two are tracked in #10707.Summary by CodeRabbit