Repository navigation
Stop committing derived metadata to main in KtsuBuild #6
Description
Activity
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.Triage
Priority: High Effort: Medium
What needs to be done: Decide whether to stop KtsuBuild committing
VERSION.md/CHANGELOG.md/LATEST_CHANGELOG.mdback tomain, 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.mdoff disk pre-commit, so package correctness isn't at risk) - If accepted, flip
shouldCommitMetadatato false for officialmainbuilds (or gate behind a setting) inCiCommand.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
- Make the accept/reject call on stale in-repo metadata between releases (the build already reads
Decision (maintainer, 2026-09-28)
Accepted: stop committing derived metadata to
main, entirely. No setting, no opt-in.- KtsuBuild writes
VERSION.md,CHANGELOG.mdandLATEST_CHANGELOG.mdinto the workspace only. It never commits or pushes them.shouldCommitMetadata(CiCommand.cs/PipelineService.cs) goes away rather than being put behind a flag. - Stale in-repo metadata is accepted. To avoid leaving misleading stale copies, delete those three files from every repo and add them to
.gitignore. That per-repo change can ride theci.ymlmigration (see Finish the pull_request paths-ignore sweep on the 16 remaining repos #5). - Acceptance criteria stand: verify a real release still produces the correct package version and GitHub release notes, since both come from the workspace copies.
Unblocks: #2 moves to the strict ruleset (require PR +
Build, Test & Release) once this ships.Related KtsuBuild bugs: KtsuBuild#160 still needs its generator fix, because
LATEST_CHANGELOG.mdfeeds release notes. KtsuBuild#172 (relative changelog paths) matters more now that the workspace copy is the only one.Next reader: implement in the KtsuBuild repo. This is not blocked on anything.
Generated by Claude Code
- KtsuBuild writes
Context
KtsuBuild commits
VERSION.md,CHANGELOG.md, andLATEST_CHANGELOG.mdback tomainduring a release, then pushes.MetadataServicestages them, commits asGithub Actions, and callsGitService.PushAsync.That push is the single reason branch rulesets cannot be enforced on this org.
github-actions[bot]holdswrite, notadmin, 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:124already computesshouldCommitMetadata = buildConfig.IsOfficial && buildConfig.IsMainand passes it asCommitChanges. When false,MetadataServicestill writes the files into the workspace, it just does not commit or push them, andReleaseHashfalls back to the current HEAD.The build reads
VERSION.mdoff disk, not out of git.Sdk.Common.MetadataFiles.propsreads 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
mainduring a release, so a strict ruleset needs no bypass actor and works everywhere.Lost:
VERSION.mdin each repo goes stale between releases, so a localdotnet packproduces a stale version numberCHANGELOG.mdstops accumulating in the repo. The GitHub release body is unaffected, sinceLATEST_CHANGELOG.mdis generated in the workspaceAcceptance criteria
shouldCommitMetadatano longer returns true for officialmainbuilds, or the behaviour is put behind a settingNote
This deserves its own design discussion rather than being bolted onto the Terraform work. It changes release behaviour across every repo in the org.