✨ feat: add a go test check to the go toolchain - #36
Conversation
The toolchain checked tidiness and vet but never ran the suite, so a repo whose only other CI was an image build had no pull-request gate on its tests at all — four repos pin this toolchain and none of them ran `go test`. Running it here rather than leaving it to each consumer's CI is not only about duplication. A suite run through a Nix shell writes its test binary under that shell's TMPDIR, and a binary that is not there at exec time fails as "fork/exec ...: no such file or directory" — a failure about the environment wearing the costume of a failure about the code. The container this module already builds has its own filesystem and the question does not arise. -count=1 disables the test cache, because a check that a previous run's cached result can satisfy is not running the thing it reports on; the mounted build cache is what keeps that affordable. The fixture gains a function and a test for it. `go test ./...` reports success against a package with no test files, so an empty fixture would have proven only that the command exits zero.
|
| Filename | Overview |
|---|---|
| go/main.go | Adds a +check method that runs the uncached Go test suite using the same container setup as the existing checks. |
| go/Makefile | Extends the test target to invoke the newly exposed check-go-test command. |
| go/fixtures/app/app.go | Adds a deterministic fixture function for compilation and test execution. |
| go/fixtures/app/app_test.go | Adds a focused unit test proving that the toolchain check executes an actual test binary. |
Reviews (1): Last reviewed commit: "✨ feat: add a go test check to the go to..." | Re-trigger Greptile
|
Closing: the premise was wrong. This was opened on the claim that four repos pin the Adding the check here would not have helped any of them, which is the more The |
1 participant
Summary
The toolchain checks tidiness and vet but never runs the suite. Four repos pin
it — tenant-api, export-cassette, search-cassette, skills-cassette — and none
of them run
go teston a pull request; for a repo whose only other CI jobbuilds an image, that means no gate on its tests at all. Three of those repos
are public, so an outside contributor's PR shows green with no suite executed.
CheckGoTestjoins the two existing checks, running in the container thismodule already builds.
Why here rather than in each consumer's CI
Not only to avoid four copies. A suite run through a Nix shell writes its test
binary under that shell's
TMPDIR, and on a GitHub runner the binary was notthere at exec time:
That is a failure about the environment wearing the costume of a failure about
the code. The container has its own filesystem and the question does not arise.
-count=1disables the test cache, because a check that a previous run'scached result can satisfy is not running the thing it reports on. The mounted
build cache keeps compilation incremental regardless.
The fixture change
go test ./...reports success against a package with no test files, so theempty fixture would have proven only that the command exits zero. It gains a
function and a test for it, and the check's output now shows the suite
actually ran:
Rollout
Adoption is per-repo and opt-in: consumers pin this module by SHA, so no
repo starts gating on its tests until it re-pins. Re-pinning the four
consumers is follow-up work, and some may have work to do before their suites
are green — which is the point.
Test plan
make -C go testgreen, with all three checks run against./fixturescheckGoTestoutput showsok example.com/fixture/app, confirming itcompiled and ran a test rather than reporting "no test files"
Part of PCC-1253