Came out of expo/universe#29409. The adopting repo lists the same paths twice: the workflow paths: filter (decides if the review job runs at all) and the routing.jsonc scope globs (decide which scope reviews each file). Nothing checks they agree. If someone adds a scope and forgets the workflow filter, the new scope is silently never reviewed.
The reviewer suggested dropping the filter and letting ecr ci return early on every PR. That costs a runner per push on a busy monorepo and adds a check line on every unrelated PR, so we would rather keep the filter and make the sync machine-checked.
Idea: a deterministic check (in ecr ref-check, or verify-config, or doctor) that parses the workflow YAML and fails when a routing.jsonc scope glob is not covered by the paths: filter. Literal match is probably enough since we generate both lists. Only when a filter exists, a workflow without paths: is always fine.
Came out of expo/universe#29409. The adopting repo lists the same paths twice: the workflow
paths:filter (decides if the review job runs at all) and the routing.jsonc scope globs (decide which scope reviews each file). Nothing checks they agree. If someone adds a scope and forgets the workflow filter, the new scope is silently never reviewed.The reviewer suggested dropping the filter and letting
ecr cireturn early on every PR. That costs a runner per push on a busy monorepo and adds a check line on every unrelated PR, so we would rather keep the filter and make the sync machine-checked.Idea: a deterministic check (in
ecr ref-check, orverify-config, ordoctor) that parses the workflow YAML and fails when a routing.jsonc scope glob is not covered by thepaths:filter. Literal match is probably enough since we generate both lists. Only when a filter exists, a workflow withoutpaths:is always fine.