Repository navigation
e2e: an empty TIA selection concludes "E2E Tests" green with no suite run #3392
Copy link
Copy link
Closed
Labels
area/ciIssues or PRs related to CI workflows, GitHub Actions, automationIssues or PRs related to CI workflows, GitHub Actions, automationkind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bug
Description
Activity
- addedkind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bugarea/ciIssues or PRs related to CI workflows, GitHub Actions, automationIssues or PRs related to CI workflows, GitHub Actions, automation
on Jul 21, 2026 - added a commit that references this issue
on Jul 29, 2026 One addition from review work on the fork e2e lane: there are now two consumers of an empty TIA selection, not one. The in-tree e2e job and the fork lane's resolve/e2e pair both read an empty selection as "skip Chainsaw" and still conclude green, so the fix should cover both call sites. The escalate-unclassified change (#3511) closes the in-tree half and, once the fork lane lands (#3262), applies to it as well, since both feed the same hack/select-e2e.sh.
- added a commit that references this issue
on Aug 8, 2026 - added a commit that references this issue
on Aug 8, 2026 - added 8 commits that reference this issue
on Aug 13, 2026 - added a commit that references this issue
on Sep 7, 2026 - added 4 commits that reference this issue
on Sep 7, 2026
Metadata
Metadata
Assignees
Labels
area/ciIssues or PRs related to CI workflows, GitHub Actions, automationIssues or PRs related to CI workflows, GitHub Actions, automationkind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bug
hack/select-e2e.shemits an empty selection for a changed path it does not recognise outsidepackages/. Both e2e lanes read an empty selection as "nothing to run": the Chainsaw step is skipped and the requiredE2E Testsstatus is postedsuccesswith zero suites executed. This affectspull-requests.yamlande2e-fork.yamlequally.Skipping is the intended behaviour for genuinely inert paths — a PR touching only
.gitignoreshould not burn a full e2e run. The defect is that the silent-ignore branch currently swallows paths that are not inert.full_suite_patterncovershack/[^/]+\.sh$andhack/[^/]+\.bats$but nothack/*.mk, so a change tohack/common-envs.mk— which supplies the tag, push and output flags of every image in the tree — selects nothing and skips e2e entirely..github/workflows/e2e-fork.yamlis in the same position:pull-requests.yamlis in the pattern, the fork lane's own workflow is not.A blanket "empty selection means full suite" fallback is the wrong fix, because it escalates exactly the inert paths the design deliberately skips. What this needs is an audit of the currently-ignored paths and an explicit classification:
hack/*.mk, shared Makefile fragments) → full suite.github/workflows/e2e-fork.yaml) → full suite.gitignore, editor config,renovate.json,*.mdoutside docs) → keep skipping, but by an explicit ruleTurning the third group into an explicit skip-list rather than a silent default is the part that matters: anything matching neither list would then escalate instead of quietly selecting nothing, so the next path someone adds fails safe rather than fails open.
This is pre-existing behaviour and not a regression from #3262 — it was found while reviewing that PR, at #3262 (comment).