README
¶
nova-ci
What it is
nova-ci: test-time budgets over go test -json output, and this repository's own CI steps
Why use it
Check test runs and their cost.
Install
go install github.com/mas-bandwidth/nova-tools/cmd/nova-ci@latest
nova-ci version
First run
The transcript below is executed line for line by the docs tests; the full record is in docs/TESTS.md.
Fixture: cmd/nova-ci/testdata/example-events.jsonl, built into the binary:
--example reads it in place of stdin, so the lines below run from the binary
alone, and they are the usage banner's example: block line for line. The
transcript was produced by running the built binary, not written by hand.
$ nova-ci slowtests --example --budget 60 --load 4 --cpus 16
CI-SLOW package=github.com/mas-bandwidth/nova-tools/internal/example seconds=65.1s budget=60s slowest=TestSlowThing:63.4s,TestAlsoSlow:1.5s
CI-LOAD load=4.00 cpus=16 per-cpu=0.25: measured, not a verdict
$ nova-ci slowtests --example --budget 120 --load 4 --cpus 16
CI-SLOW OK packages=2 slowest=github.com/mas-bandwidth/nova-tools/internal/example:65.1s
CI-LOAD load=4.00 cpus=16 per-cpu=0.25: measured, not a verdict
Verbs
The nova-ci section of the command reference documents every verb's flags, effect and exit codes.
helpversionslowtestsfunctionallocalnew-rulenew-verbbenchgithub
Spec
The contract is docs/SPEC-CI.md.
Documentation
¶
Overview ¶
nova-ci runs the checks this repository's CI path makes on its own output. Its first verb, slowtests, reads the newline-delimited `go test -json` TestEvents on stdin, sums the package-level elapsed time for each package, and prints a CI-SLOW line for every package whose total is over the budget, a measurement that fails the run only under --enforce, so a slow test surfaces the moment it happens.
Every path and every budget comes from a flag. There are no guessed paths; a budget of zero or less is refused rather than read as unlimited.
nova-ci version: which build made a CI verdict.
A CI-SLOW line is only worth reading if the binary that printed it is the one that was built from the commit under review, and the release assertion holds every shipped tool to reporting its tag. The identity is read from the build itself -- a release's -ldflags "-X main.version=<tag>", then the installed module version, then the vcs stamp, then the honest floor `devel` -- by pkg/buildinfo, so all shipped tools answer in the same one line: `<tool> <version> <goos>/<goarch> <go version>`.
Source Files