Documentation-only PRs for the permits portal still trigger expensive load tests. What workflow change is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Path filters are the "don't run the full fire drill for a typo in the permits README" rule. Skipping load tests for docs-only changes saves the heavy gear for real code.
Full Explanation
Conditional execution with path filters skips expensive jobs when only documentation paths change, preserving CI capacity for application-impacting diffs. Documentation-only PRs for the permits portal should not trigger full load tests; path filters or conditions should skip those heavy jobs while still running them when application code changes. The correct workflow change works because load tests are costly in time and infrastructure; running them for README typos wastes municipal CI budget and slows documentation improvements that do not affect runtime behavior.
Always running full load tests on every README typo fix fails because it couples unrelated documentation velocity to the most expensive validation stage. Disabling load tests for all PRs including application code changes fails conceptually: the goal is selective skipping, not eliminating load validation for real permits-portal code. Requiring load tests only on holidays when staff are unavailable fails because calendar gimmicks are not path-based conditions and leave ordinary weekdays either over- or under-tested.
Exam caveat: path filters must be accurate—do not skip load tests when docs and application paths change together; prefer filters that run load tests if any non-doc path is touched. Operational check: open a permits-portal PR that only edits documentation and confirm load tests are skipped; open a PR that changes application code and confirm load tests run; review filter patterns whenever the repository directory layout changes.