Stop the shared ci.yml template filtering paths on pull_request

[matt-edmondson]

Refs #5 — this fixes the root cause, but does not on its own complete that issue's sweep. See What this does not do below.

Why #5's sweep did not stick

The issue says the filter "has been removed from the pull_request trigger in 41 repos". Measured against current main, that is no longer true of any of them.

I sampled 28 repositories — the 15 the issue names as remaining, plus 13 it counts as already swept as a control — by fetching each one's .github/workflows/dotnet.yml and parsing the trigger block. All 28 still carry paths-ignore under pull_request. The control group was the interesting half: if the sweep had held anywhere, it would have held there.

CaseConverter's history explains it:

commit	date	pull_request
cf13319 "always run CI on pull requests"	2026-08-23	no filter — the sweep
a4cec36 "adopt the unified dotnet workflow"	2026-08-26	filter back
53bf50b "adopt the consolidated .NET workflow"	2026-09-14	filter still there

The sweep landed and was undone three days later, not deliberately but as a side effect of replacing the whole workflow file. 53bf50b's own message describes the replacement as "byte-identical in every repository", so the revert was broadcast fleet-wide a second time.

Sweeping the repositories again without changing the template they are regenerated from would be reverted a third time.

The change

docs/shared-ci.md holds the canonical ci.yml "every repository holds byte-identical". It carried paths-ignore on both triggers. This removes it from pull_request only.

That trigger is the one that matters, because a filtered pull_request trigger does not report a neutral check — it reports nothing. Any ruleset requiring Build, Test & Release therefore blocks a docs-only pull request permanently, with no check to wait on and nothing to override. It also catches pull requests editing DESCRIPTION.md and TAGS.md, which the Terraform workspace derives repository metadata from.

The push filter stays, deliberately. Release gating runs off KtsuBuild's should_release rather than the event type, so a docs-only push to main would otherwise cut a version.

That asymmetry is now stated in the document rather than left implicit, because making the two triggers symmetric is the obvious tidy-up and is exactly what undid it twice.

Tests

scripts/tests/shared-ci-template.tests.ps1, following the existing update-sdks.tests.ps1 convention in this repo — a plain pwsh script with the same harness shape, run directly, non-zero exit on failure.

case	guards
pull_request does not filter paths	the regression itself
push still filters paths	the obvious over-correction, which would cut spurious releases
both triggers are still declared	a rewrite that drops pull_request entirely, which would pass the first case for the wrong reason

The block is located by the sentence that introduces it rather than by being the first fenced block in the file, so adding an example earlier in the document cannot silently point the assertions at the wrong YAML.

Proved failing without the fix. Reverting only docs/shared-ci.md to main and keeping the test:

FAIL  pull_request does not filter paths
      pull_request carries paths-ignore:
          paths-ignore:
            ["**.md", ".github/ISSUE_TEMPLATE/**", ".github/pull_request_template.md"]
ok    push still filters paths
ok    both triggers are still declared

1 of 3 case(s) failed.     exit 1

With the fix: 3 of 3 passed, exit 0.

Verification

• scripts/tests/shared-ci-template.tests.ps1 — 3/3 passed
• scripts/tests/update-sdks.tests.ps1 — 7/7 passed, unchanged
• markdownlint docs/shared-ci.md — clean

Run on PowerShell 7.4.6 on Linux. Worth recording: pwsh is not installed in this container and dotnet tool install is broken here for every package (Settings file 'DotnetToolSettings.xml' was not found, reproducible with Microsoft's own dotnetsay), which is the same container limitation recorded on ktsu-dev/Sdk#34. The official tarball from GitHub releases works and is what I used.

What this does not do

It does not sweep the repositories, so #5 stays open. Two things remain there, and both are yours:

1. The 28+ repositories still on a standalone dotnet.yml. The issue's "16 remaining" count is stale in the other direction too — it is effectively all of them. That sweep still needs the routing decision asked for on Finish the pull_request paths-ignore sweep on the 16 remaining repos #5 on 2026-09-22 and not yet answered: 16-plus one-file pull requests, or direct [skip ci] pushes. I have not made that call.
2. No repository has adopted ci.yml yet. None of the 28 sampled has one, so the shared-pipeline migration this template belongs to has not started. That is worth knowing on its own, since CLAUDE.md describes --fallback-workflow dotnet.yml as a migration crutch that "comes off once the warnings stop" — currently it is carrying the entire fleet.

The upside of ordering it this way is that whenever the migration does run, repositories land on a template that is already correct.

🤖 Generated with Claude Code

https://claude.ai/code/session_012PwjCMZsvWpvHQhPu5kvBX

---

Generated by Claude Code