Summary
The Server Linux validation release dry-run fails because the new global Git
LFS attributes classify go.mod as an LFS file. On a normal LFS-enabled
checkout, go.mod becomes modified before the package script's clean-worktree
guard runs.
Evidence
- Failing run: Server validation #32659914152
- Revision:
132ac682e6203645fb83c38f8f1945d4397166ff
- That commit only adds
.gitattributes, including the generic rule
*.mod filter=lfs diff=lfs merge=lfs -text.
go.mod matches that pattern. In a fresh clone, running
git lfs install --local and checking out HEAD reports
Encountered 1 file that should have been a pointer, but wasn't: go.mod
and git status reports M go.mod.tools/package-release.sh then exits with
release packaging requires a clean tracked and untracked worktree.- The previous Server validation at
#32522072639
was green before the .gitattributes commit.
Analysis
The extension-wide LFS rule is too broad for a Go repository: .mod is both an
audio/module asset suffix and the suffix of Go's module manifest. The release
guard is correctly refusing to package a checkout whose tracked bytes no
longer match Git.
Proposed solution
- Remove the generic
*.mod rule from Server (there are no Server-owned audio
assets), or replace it with path-specific rules that cannot match go.mod.
Audit the remaining extension rules for source/config collisions before
merging the fix.
- Add a CI attribute regression check that initializes Git LFS in a clean
checkout, asserts go.mod has no LFS filter and remains clean, and then runs
the package dry-run.
- Keep the release guard, but include the offending
git status --porcelain
paths in its diagnostic so future attribute regressions are immediately
actionable.
Acceptance criteria
- Fresh LFS-enabled checkouts remain clean and
go.mod is a normal text file.
- Linux and Windows validation, including two deterministic package builds,
pass at the fixed revision.
- No broad LFS pattern classifies Go manifests or other tracked source/config
files.
Summary
The Server Linux validation release dry-run fails because the new global Git
LFS attributes classify
go.modas an LFS file. On a normal LFS-enabledcheckout,
go.modbecomes modified before the package script's clean-worktreeguard runs.
Evidence
132ac682e6203645fb83c38f8f1945d4397166ff.gitattributes, including the generic rule*.mod filter=lfs diff=lfs merge=lfs -text.go.modmatches that pattern. In a fresh clone, runninggit lfs install --localand checking outHEADreportsEncountered 1 file that should have been a pointer, but wasn't: go.modand
git statusreportsM go.mod.tools/package-release.shthen exits withrelease packaging requires a clean tracked and untracked worktree.#32522072639
was green before the
.gitattributescommit.Analysis
The extension-wide LFS rule is too broad for a Go repository:
.modis both anaudio/module asset suffix and the suffix of Go's module manifest. The release
guard is correctly refusing to package a checkout whose tracked bytes no
longer match Git.
Proposed solution
*.modrule from Server (there are no Server-owned audioassets), or replace it with path-specific rules that cannot match
go.mod.Audit the remaining extension rules for source/config collisions before
merging the fix.
checkout, asserts
go.modhas no LFS filter and remains clean, and then runsthe package dry-run.
git status --porcelainpaths in its diagnostic so future attribute regressions are immediately
actionable.
Acceptance criteria
go.modis a normal text file.pass at the fixed revision.
files.