Windows: init/track tests write through to the real user config.yaml — HOME isolation no-ops
Symptom
On Windows, running the cmd/gortex test suite pollutes the developer's live repo inventory: after a plain
the real user-level config.yaml gains tracked-repo entries pointing at the suite's temp directories:
repos:
- path: D:\Cache\Temp\TestInitCreatesProjectMarker3612887292\001
- path: D:\Cache\Temp\TestInitRefusesHomeDirectory551333095\001The temp dirs are gone by then (t.TempDir cleanup), so the next daemon start greets you with
!! 4 tracked repos no longer exist on disk — the path was deleted, renamed, or unmounted
and each corpse has to be untracked by hand. I've hit this four times in the past week — every local verification run over cmd/gortex regrows a few TestInit* entries.
Cause
The tests DO try to isolate: init_integration_test.go sets t.Setenv("HOME", t.TempDir()) before running runInit. But the config path is resolved through os.UserHomeDir() (cmd/gortex/init.go:235, :374), and on Windows that reads %USERPROFILE%, not HOME — so the override is a silent no-op and the init/track side effects land in the real ~/.gortex/config.yaml. On macOS/Linux the isolation works, which is why CI never sees it.
Repro (Windows)
- Note your user-level
config.yaml repo list.
go test -count=1 -run "TestInit" ./cmd/gortex/- Diff the config: new
repos: entries under the temp root appear; the directories themselves are already gone.
Suggested fix
Either per-test: set USERPROFILE alongside HOME in the same t.Setenv blocks (cheap, but every future test must remember both), or centrally: a shared test helper that redirects the user config dir cross-platform — the daemon integration suite's spinUpDaemonWithConfig pattern already points everything at a test-scoped config and never leaks. Belt and braces: fail the suite if the real user config's mtime changes during a run, so the isolation can't regress silently again.
Happy to send a PR — the per-test fix is a handful of lines.
Windows: init/track tests write through to the real user config.yaml — HOME isolation no-ops
Symptom
On Windows, running the
cmd/gortextest suite pollutes the developer's live repo inventory: after a plainthe real user-level
config.yamlgains tracked-repo entries pointing at the suite's temp directories:The temp dirs are gone by then (
t.TempDircleanup), so the next daemon start greets you withand each corpse has to be untracked by hand. I've hit this four times in the past week — every local verification run over
cmd/gortexregrows a fewTestInit*entries.Cause
The tests DO try to isolate:
init_integration_test.gosetst.Setenv("HOME", t.TempDir())before runningrunInit. But the config path is resolved throughos.UserHomeDir()(cmd/gortex/init.go:235,:374), and on Windows that reads%USERPROFILE%, notHOME— so the override is a silent no-op and the init/track side effects land in the real~/.gortex/config.yaml. On macOS/Linux the isolation works, which is why CI never sees it.Repro (Windows)
config.yamlrepo list.go test -count=1 -run "TestInit" ./cmd/gortex/repos:entries under the temp root appear; the directories themselves are already gone.Suggested fix
Either per-test: set
USERPROFILEalongsideHOMEin the samet.Setenvblocks (cheap, but every future test must remember both), or centrally: a shared test helper that redirects the user config dir cross-platform — the daemon integration suite'sspinUpDaemonWithConfigpattern already points everything at a test-scoped config and never leaks. Belt and braces: fail the suite if the real user config's mtime changes during a run, so the isolation can't regress silently again.Happy to send a PR — the per-test fix is a handful of lines.