devantler-tech / devantler-tech/ksail

fix(test): report the underlying go list error, not just its exit status

Open Beginner friendly
#6,977 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.