pr.yaml: write protected config files as UTF-8 without BOM by Chris-Wolfgang · Pull Request #339 · Chris-Wolfgang/repo-template

Chris-Wolfgang · 2026-05-09T17:59:15Z

Summary

The "Fetch trusted configuration files from main branch" step in pr.yaml (in both the v3 gated workflow's main-tests job and the secondary tests job) writes the protected config files back to disk via:

git show "main-branch:$configFile" | Out-File -FilePath $configFile -Encoding UTF8 -NoNewline

In PowerShell, -Encoding UTF8 writes UTF-8 with a BOM. The .NET analyzer engine that reads .editorconfig appears to silently ignore files that begin with a BOM — so the project's severity overrides (e.g. dotnet_diagnostic.MA0002.severity = suggestion) don't apply on CI even though they apply locally. Analyzers fire at their default severity instead, and TreatWarningsAsErrors then escalates them.

This was diagnosed against Chris-Wolfgang/In-memory-Logger PR #32 / run 24996715587: local Release builds were clean while CI reported MA0002, MA0049, S2365, S1066, MA0158, S1481, S2699 as errors. After repointing the build to the BOM-free version of .editorconfig, the same source compiled clean.

Fix

Switch the four call sites to Out-File -Encoding UTF8NoBOM. PS 6+ supports this encoding token; GitHub-hosted shell: pwsh runners use PowerShell 7+, so it's safe.

Downstream impact

The bug exists in every consumer repo's pr.yaml. They'll pick up the fix on their next template-sync. No retroactive flush needed — once the BOM-free .editorconfig lands on main, subsequent PRs will see the analyzer config applied as intended.

Test plan

CI on this PR passes (the same protected-files mechanism runs on this PR)
After merge, sync into one consumer repo (e.g. In-memory-Logger) and verify a Release build of an existing PR no longer trips analyzer rules that the project's .editorconfig marks as suggestion

🤖 Generated with Claude Code

The "Fetch trusted configuration files from main branch" step writes .editorconfig / Directory.Build.props / BannedSymbols.txt / *.globalconfig / *.ruleset back to disk via `Out-File -Encoding UTF8`. In PowerShell, that encoding name writes UTF-8 *with* a BOM. The .NET analyzer engine that reads .editorconfig appears to silently ignore files that begin with a BOM, which means the project's severity overrides (e.g. `dotnet_diagnostic.MA0002.severity = suggestion`) don't apply on CI even though they apply locally — analyzers fire at their default severity instead. This was diagnosed against In-memory-Logger PR #32 / run 24996715587: local Release builds were clean while CI reported MA0002, MA0049, S2365, etc. as errors. After repointing the build to the BOM-free version of .editorconfig, the same source compiled clean. Switch to `Out-File -Encoding UTF8NoBOM` (PowerShell 6+; GitHub-hosted `shell: pwsh` runners use PS 7+ so this is supported). Four sites in the two "Fetch trusted configuration files" blocks. Downstream consumers will pick up the fix the next time they run their template-sync. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the workflow’s “Fetch trusted configuration files from main branch” step to write protected config files as UTF-8 without a BOM, preventing .NET analyzer configuration files (e.g., .editorconfig) from being ignored on CI due to BOM-prefixed content.

Changes:

Replaced Out-File -Encoding UTF8 with Out-File -Encoding UTF8NoBOM at four workflow call sites.
Keeps existing -NoNewline behavior while ensuring analyzer configuration files remain BOM-free.

Each of test-linux-core, test-windows, test-macos-core, and security-scan ran the "Fetch trusted configuration files from main branch" step twice back-to-back with identical content (modulo trailing whitespace). Drop the second occurrence in all four jobs so the protected configs are restored once per job, not twice. Net effect: 192 lines deleted, no behavior change — second copy was a no-op since main's configs are already on disk after the first run. The single remaining occurrence per job retains the same UTF8NoBOM encoding behavior introduced in #339. Flagged by Copilot review on the downstream backport Chris-Wolfgang/ETL-FixedWidth#90 (which this fixes at the canonical source so every Wolfgang.* repo picks it up on the next sync).

Backport of repo-template PR #339. The 'Fetch trusted configuration files from main branch' step writes .editorconfig / Directory.Build.props / BannedSymbols.txt back via 'Out-File -Encoding UTF8' which writes UTF-8 *with* BOM. The .NET analyzer engine appears to ignore .editorconfig files prefixed by a BOM, so project-level severity overrides don't apply on CI even though they apply locally — analyzers fire at default severity and TreatWarningsAsErrors then escalates them to errors. Switch to 'Out-File -Encoding UTF8NoBOM' (PS 6+; the runner uses pwsh). Diagnosed against Chris-Wolfgang/In-memory-Logger PR #32 / run 24996715587. See Chris-Wolfgang/repo-template#339 for the full write-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Backport of [repo-template#339](Chris-Wolfgang/repo-template#339). The 'Fetch trusted configuration files from main branch' step writes the protected configs back via `Out-File -Encoding UTF8` (BOM-prefixed). The .NET analyzer engine appears to ignore BOM-prefixed `.editorconfig` files, so project severity overrides don't apply on CI — analyzers fire at default severity and `TreatWarningsAsErrors` escalates findings that pass locally. This is a 4-line workflow-only change: `UTF8` → `UTF8NoBOM` at the four call sites. PowerShell 6+ supports the encoding token; `shell: pwsh` runners use PS 7+, so it's safe. Diagnosed against [In-memory-Logger PR #32 / run 24996715587](https://github.com/Chris-Wolfgang/In-memory-Logger/actions/runs/24996715587/job/73195928572). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Backport of repo-template PR #339. The 'Fetch trusted configuration files from main branch' step writes .editorconfig / Directory.Build.props / BannedSymbols.txt back via 'Out-File -Encoding UTF8' which writes UTF-8 *with* BOM. The .NET analyzer engine appears to ignore .editorconfig files prefixed by a BOM, so project-level severity overrides don't apply on CI even though they apply locally — analyzers fire at default severity and TreatWarningsAsErrors then escalates them to errors. Switch to 'Out-File -Encoding UTF8NoBOM' (PS 6+; the runner uses pwsh). Diagnosed against Chris-Wolfgang/In-memory-Logger PR #32 / run 24996715587. See Chris-Wolfgang/repo-template#339 for the full write-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot AI review requested due to automatic review settings May 9, 2026 17:59

Copilot started reviewing on behalf of Chris-Wolfgang May 9, 2026 17:59 View session

Chris-Wolfgang merged commit f3c58ee into main May 9, 2026
10 of 11 checks passed

Chris-Wolfgang deleted the fix/pr-yaml-bom-on-protected-config-fetch branch May 9, 2026 18:04

Copilot AI reviewed May 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pr.yaml: write protected config files as UTF-8 without BOM#339

pr.yaml: write protected config files as UTF-8 without BOM#339
Chris-Wolfgang merged 1 commit into
mainfrom
fix/pr-yaml-bom-on-protected-config-fetch

Chris-Wolfgang commented May 9, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Chris-Wolfgang commented May 9, 2026

Summary

Fix

Downstream impact

Test plan

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants