devantler-tech / devantler-tech/ksail
fix(test): report the underlying go list error, not just its exit status
- Dominant language
- Go
- Stars
- 165
- Forks
- 12
- Avg merge
- 5h 51m
- Merged PRs (30d)
- 347
Description
> 🤖 Generated by the Agentic Engineer
## Evidence
When the `desktop` module's graph is stale, `TestClaircoreLinkedPackagesStayInert/desktop` fails like this:
```
--- FAIL: TestClaircoreLinkedPackagesStayInert/desktop (3.40s)
claircore_linkage_test.go:164: go list -deps ./... in module ".../desktop" failed: exit status 1
FAIL github.com/devantler-tech/ksail/v7/pkg/client/kubescape
```
The test shells out to `go list -deps ./...`, and on failure reports only the **exit status**. The actual cause — `go: updates to go.mod needed; to update it:\n\tgo mod tidy` — is on the subprocess's stderr and is discarded.
This was one of the four checks failing on #6971/#6972/#6973. Diagnosing it required pulling the *other* failing job's log from a different workflow, because this one, despite naming the exact module at fault, said nothing about why.
## Impact
`go list -deps` fails for several genuinely different reasons — a stale module graph, an unresolvable requirement, a syntax error in a `go.mod`, a network failure fetching a module. All of them surface here as the same six characters, so the test tells you *where* to look but never *what* is wrong, and the reader has to go find a different job that happened to print the real error. Where no such job exists, the information is simply gone.
## Expected behaviour
The failure names the underlying `go list` stderr, so the cause is diagnosable from this test's output alone.
## Acceptance criteria
- [ ] `claircore_linkage_test.go:164` includes the subprocess's captured stderr in its failure message (bounded, so a large output does not swamp the log).
- [ ] The other `exec` call sites in the same test are checked for the same pattern and given the same treatment where they have it.
- [ ] A test proves the stderr actually reaches the message — e.g. by pointing the helper at a module directory that fails to resolve and asserting the message contains the real `go` diagnostic rather than only `exit status 1`.
**Size:** small. Mechanical change to error construction plus one test.
Split out from #6974's third acceptance criterion: that issue's cause turned out to be a CI delivery defect (fixed in #6976), which is independent of this diagnostics gap. Filed separately so it is not closed along with it.
Contributor guide
Research direction
Start in claircore_linkage_test.go at line 164, where go list -deps ./... is run, and inspect the other exec call sites in the same test. Trace how the helper constructs failures and run the relevant test against a module directory that produces a go diagnostic. Done means bounded stderr appears in the failure message and a test verifies the underlying diagnostic is retained.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 82/100