Stop committing derived metadata to main in KtsuBuild

[matt-edmondson]

Context

KtsuBuild commits VERSION.md, CHANGELOG.md, and LATEST_CHANGELOG.md back to main during a release, then pushes. MetadataService stages them, commits as Github Actions, and calls GitService.PushAsync.

That push is the single reason branch rulesets cannot be enforced on this org. github-actions[bot] holds write, not admin, and GitHub Actions cannot be a ruleset bypass actor here because it is not an installed app. So any ruleset requiring a pull request blocks releases.

The observation

The commit is not needed for a correct release. CiCommand.cs:124 already computes shouldCommitMetadata = buildConfig.IsOfficial && buildConfig.IsMain and passes it as CommitChanges. When false, MetadataService still writes the files into the workspace, it just does not commit or push them, and ReleaseHash falls back to the current HEAD.

The build reads VERSION.md off disk, not out of git. Sdk.Common.MetadataFiles.props reads it at build time, and KtsuBuild writes it before the build runs. So the published package carries the right version whether or not the file is ever committed.

These are derived artifacts. The version comes from git tags, and the changelog comes from commit history. Committing them back into source is what created the constraint.

What changes if the commit is dropped

Gained: no push to main during a release, so a strict ruleset needs no bypass actor and works everywhere.

Lost:

• VERSION.md in each repo goes stale between releases, so a local dotnet pack produces a stale version number
• CHANGELOG.md stops accumulating in the repo. The GitHub release body is unaffected, since LATEST_CHANGELOG.md is generated in the workspace

Acceptance criteria

• A decision on whether stale in-repo metadata is acceptable
• If yes, shouldCommitMetadata no longer returns true for official main builds, or the behaviour is put behind a setting
• A release is verified to still produce the correct package version and release notes
• The ruleset issue is revisited, since this unblocks the strict option

Note

This deserves its own design discussion rather than being bolted onto the Terraform work. It changes release behaviour across every repo in the org.

[matt-edmondson]

This is the clean fix for #2. Dropping the metadata commit removes the push to main, after which a strict ruleset needs no bypass actor at all.

[matt-edmondson]

Triage

Priority: High Effort: Medium

What needs to be done: Decide whether to stop KtsuBuild committing VERSION.md/CHANGELOG.md/LATEST_CHANGELOG.md back to main, since that push is the sole reason a strict branch ruleset can't be enforced org-wide.

Suggested next steps / acceptance criteria:

• Make the accept/reject call on stale in-repo metadata between releases (the build already reads VERSION.md off disk pre-commit, so package correctness isn't at risk)
• If accepted, flip shouldCommitMetadata to false for official main builds (or gate behind a setting) in CiCommand.cs
• Verify a release still produces correct package version + GitHub release notes with the commit removed
• Revisit .github#2 once this lands, since it unblocks the strict ruleset option

Blockers / dependencies: This is the clean fix that unblocks .github#2 (branch ruleset strategy). Needs its own design discussion per the issue's own note, since it changes release behavior org-wide

---

Generated by Claude Code