The problem
Coverage is not reported anywhere. Finding out that pkg/docker sits at 17.7% required running go test -cover by hand and reading the output.
For a project asking people to trust it with untrusted code, the coverage of the isolation engine should be visible — to maintainers as a trend, and to anyone evaluating the library.
What to add
- upload a coverage profile on every CI run and report the delta on pull requests
- a badge in the README
- track the packages separately, since a single repository-wide number would average the well-covered pure logic together with the engine and hide exactly the gap that matters
Deliberately not proposing a coverage gate
A minimum-coverage check would be counterproductive here. Much of pkg/docker is genuinely only reachable against a live daemon, so a gate on the unit run would push people toward mocking the Docker API — which tests the mock, not the engine. Once #3 runs the integration suite in CI, the combined number becomes meaningful and a floor could be revisited then.
Visibility first; enforcement only if it turns out to be needed.
The problem
Coverage is not reported anywhere. Finding out that
pkg/dockersits at 17.7% required runninggo test -coverby hand and reading the output.For a project asking people to trust it with untrusted code, the coverage of the isolation engine should be visible — to maintainers as a trend, and to anyone evaluating the library.
What to add
Deliberately not proposing a coverage gate
A minimum-coverage check would be counterproductive here. Much of
pkg/dockeris genuinely only reachable against a live daemon, so a gate on the unit run would push people toward mocking the Docker API — which tests the mock, not the engine. Once #3 runs the integration suite in CI, the combined number becomes meaningful and a floor could be revisited then.Visibility first; enforcement only if it turns out to be needed.