Skip to content

Add .github/workflows/* to protected file detection#88

Merged
Chris-Wolfgang merged 2 commits into
mainfrom
chore/protect-workflow-files
Apr 27, 2026
Merged

Add .github/workflows/* to protected file detection#88
Chris-Wolfgang merged 2 commits into
mainfrom
chore/protect-workflow-files

Conversation

@Chris-Wolfgang
Copy link
Copy Markdown
Owner

Why

The "Detect protected configuration file changes" step in `pr.yaml` already fails the build (with a maintainer-review message) if a PR modifies `.editorconfig`, `Directory.Build.props/.targets`, `BannedSymbols.txt`, `.globalconfig`, or `.ruleset`. This PR extends that protection to `.github/workflows/.yml`/`.yaml`.

Why it matters

`pull_request_target` already sources the workflow from `main`, so a malicious PR modifying `pr.yaml` on its branch can't actually take effect. But:

  • A subtly broken workflow YAML (e.g. duplicate mapping key) can silently disable CI without errors. We hit this exact failure mode for ~2 weeks of merges this month before tracking it down to a duplicate `run:` key.
  • If the trigger is ever flipped back to `pull_request`, workflow files would suddenly run from PR branches — and we'd get no signal that they changed.

Failing fast on workflow modifications gives maintainers a clear "review this carefully" signal regardless of the trigger model.

Changes

  • 4 bash `Fetch trusted configuration files` steps (detect-projects, test-linux-core, test-macos-core, security-scan): added `.github/workflows/.yml` and `.github/workflows/.yaml` to `config_files=()`
  • 1 PowerShell `Fetch trusted configuration files` step (test-windows): added the same patterns to `$globPatterns`
  • 1 `Detect protected configuration file changes` step: extended the regex to also match `^.github/workflows/.*.ya?ml$`

Verification

  • YAML parses cleanly: `name='PR Checks v3 (Gated)'`, trigger=`pull_request_target`, 6 jobs
  • Regex tested against sample file paths — matches workflow YAML/YML, still matches `.globalconfig`/`.ruleset`, doesn't match unrelated paths
  • Net diff: +12 lines, -4 lines

🤖 Generated with Claude Code

Extends the trusted-config-fetch and protected-file-detect logic in
pr.yaml to cover workflow files. PRs that modify any .yml/.yaml under
.github/workflows/ now fail with the maintainer-review message,
consistent with how .editorconfig, Directory.Build.*, BannedSymbols.txt,
*.globalconfig, and *.ruleset are already handled.

Defense in depth: even though pull_request_target sources the workflow
from main (not the PR branch), failing loudly when workflow files are
touched gives a clear maintainer signal regardless of the trigger model.

Changes:
- 4 bash 'Fetch trusted configuration files' steps: added 2 workflow
  glob patterns to config_files=()
- 1 PowerShell 'Fetch trusted configuration files' step: added 2 patterns
  to $globPatterns
- 1 'Detect protected configuration file changes' step: extended the
  grep regex to also match ^\.github/workflows/.*\.ya?ml$

Verified: YAML still parses cleanly (name='PR Checks v3 (Gated)',
trigger='pull_request_target', 6 jobs). Regex tested against sample
file paths.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Chris-Wolfgang Chris-Wolfgang merged commit cc2961c into main Apr 27, 2026
8 checks passed
@Chris-Wolfgang Chris-Wolfgang deleted the chore/protect-workflow-files branch April 27, 2026 23:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant