Reference version
2.1.19-preview (gap highlighted by the Codecov report on PR #319)
Background and motivation
Since #319, PostReleaseHookContext is the typed contract between bv and repo-owned post-release hooks. ReleaseCommand assembles it inline (ReleaseCommand.cs#L243-L266): well-known paths (with Path.GetFullPath anchoring for the artifacts and scratch directories), release/version fields, produced packages, and the dogfooding flag — plus the working-tree snapshot diff that detects which files the hook modified.
None of this is unit-tested: ReleaseCommand is a large orchestrator that resolves a dozen services and only runs on cloud builds, so it has no test harness at all. Codecov flags the 14 new context-assembly lines at 0% patch coverage. A mistake in path anchoring, a mixed-up version field (Version vs SemVer), or a regression in the dirty-files diffing would only surface during an actual release — the worst possible moment, since releases are not rehearsable locally.
Proposed enhancement
The hook-context assembly and the hook-change detection logic are covered by unit tests. bv's observable behavior does not change.
Implementation proposals
- Extract the context assembly from
ReleaseCommand into a small internal factory (e.g., PostReleaseHookContextFactory in Buildvana.Tool/Services/Hooks/) taking the home directory provider, artifacts path, version information, produced packages, and dogfood flag. ReleaseCommand delegates to it.
- Move the "snapshot dirty files around the hook run" logic next to
HookRunner (e.g., a helper that runs a hook and returns the set of files it modified), so it can be tested with the fakes already used by HookRunnerTests.
- Add tests in
Buildvana.Tool.Tests alongside HookRunnerTests and PostReleaseHookContextTests: path anchoring (relative artifacts path → absolute), version field mapping including PreviousVersion = null for a first release, and modified-file detection (no changes / changes / hook absent).
Usage examples
Not user-facing; example of the kind of test this enables:
[Test]
public async Task CreateContext_AnchorsArtifactsPathToWorkingDirectory() { /* ... */ }
Risks
Refactor-only; no public surface or behavior change, so no changelog entry needed. Main risk is cosmetic churn in ReleaseCommand; the extraction is mechanical.
Additional information
Flagged as a non-blocking note in the PR #319 review; acknowledged as a pre-existing gap in this reply.
Reference version
2.1.19-preview (gap highlighted by the Codecov report on PR #319)
Background and motivation
Since #319,
PostReleaseHookContextis the typed contract betweenbvand repo-owned post-release hooks.ReleaseCommandassembles it inline (ReleaseCommand.cs#L243-L266): well-known paths (withPath.GetFullPathanchoring for the artifacts and scratch directories), release/version fields, produced packages, and the dogfooding flag — plus the working-tree snapshot diff that detects which files the hook modified.None of this is unit-tested:
ReleaseCommandis a large orchestrator that resolves a dozen services and only runs on cloud builds, so it has no test harness at all. Codecov flags the 14 new context-assembly lines at 0% patch coverage. A mistake in path anchoring, a mixed-up version field (VersionvsSemVer), or a regression in the dirty-files diffing would only surface during an actual release — the worst possible moment, since releases are not rehearsable locally.Proposed enhancement
The hook-context assembly and the hook-change detection logic are covered by unit tests.
bv's observable behavior does not change.Implementation proposals
ReleaseCommandinto a small internal factory (e.g.,PostReleaseHookContextFactoryinBuildvana.Tool/Services/Hooks/) taking the home directory provider, artifacts path, version information, produced packages, and dogfood flag.ReleaseCommanddelegates to it.HookRunner(e.g., a helper that runs a hook and returns the set of files it modified), so it can be tested with the fakes already used byHookRunnerTests.Buildvana.Tool.TestsalongsideHookRunnerTestsandPostReleaseHookContextTests: path anchoring (relative artifacts path → absolute), version field mapping includingPreviousVersion = nullfor a first release, and modified-file detection (no changes / changes / hook absent).Usage examples
Not user-facing; example of the kind of test this enables:
Risks
Refactor-only; no public surface or behavior change, so no changelog entry needed. Main risk is cosmetic churn in
ReleaseCommand; the extraction is mechanical.Additional information
Flagged as a non-blocking note in the PR #319 review; acknowledged as a pre-existing gap in this reply.