fix(ci): unblock Dependabot upgrades (test brittleness, gotestsum on Go 1.25)#18
Merged
Merged
Conversation
Three pre-existing fragilities surface when bumping deps: 1. pkg/cmd/flag/*_test.go used reflect.DeepEqual on error values. pflag 1.0.7+ wraps underlying parse errors with fmt.Errorf(...: %w), producing a different concrete type even when the rendered message is identical. Switch to comparing err.Error() strings via a small errorMessage(err) helper in flag_helpers_test.go. 2. expectedError literals previously used fmt.Errorf with a format string; switched to errors.New with concatenation. Removes Go 1.24 vet's 'non-constant format string' concern for future churn. 3. CI: gotestsum v1.12.0 transitively imports golang.org/x/tools v0.19.0, which fails to compile on Go 1.25 (invalid array length -delta*delta in tokeninternal.go:64). Once any dep bump pushes go.mod past go 1.24.0 (e.g. x/time v0.15+), the 'Install gotestsum' step fails. Bump to gotestsum v1.13.0, which pulls newer x/tools that compiles on both 1.24 and 1.25. Smoke-tested locally against the three currently-open Dependabot PR targets: - pflag 1.0.6 -> 1.0.10: pkg/cmd/flag tests green - cobra 1.10.2 + pflag 1.0.9: pkg/cmd tests green - gotestsum v1.13.0: installs cleanly on Go 1.24 and Go 1.25
2 tasks
piotr-roslaniec
added a commit
that referenced
this pull request
May 23, 2026
govulncheck v1.1.1 transitively imports golang.org/x/tools@v0.21.1,
which contains an array-length trick in internal/tokeninternal/tokeninternal.go:64
that evaluates to -256 on Go 1.25 and fails to compile:
invalid array length -delta * delta (constant -256 of type int64)
This blocks any dep bump that pushes go.mod past go 1.24.0 (e.g. PR #11's
golang.org/x/time v0.15.0, which requires go 1.25.0).
govulncheck v1.1.4 uses x/tools v0.29.0, which doesn't have that pattern.
v1.1.4 still requires only Go 1.22.0 minimum, so it works on both Go 1.24
(current main) and Go 1.25 (post-#11). Holding back from v1.2.0 because
v1.2.0+ requires Go 1.25.0 minimum, which would prematurely force the
toolchain floor before consumers are ready.
Pairs with #18's gotestsum v1.12.0 -> v1.13.0 bump for the same
underlying issue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three open Dependabot PRs (#7, #10, #11) fail CI today against current main for reasons that aren't really about the bumps themselves — they're pre-existing fragilities that the bumps surface. This PR fixes those fragilities on main so the next Dependabot rebase lands cleanly.
What this fixes
1. `pkg/cmd/flag` tests use `reflect.DeepEqual` on errors
`flag_big_int_test.go:47` and `flag_wei_test.go:65` compare expected vs. actual errors via `reflect.DeepEqual`. pflag 1.0.7+ wraps underlying parse errors with `fmt.Errorf("...: %w", inner)`, producing a different concrete type even when the rendered message is identical. Result: tests fail with logs that look like
```
expected: invalid argument "100k" for "--amount" flag: failed to parse as big.Int: 100k
actual: invalid argument "100k" for "--amount" flag: failed to parse as big.Int: 100k
```
…where the two strings are byte-for-byte equal. Fixed by comparing `err.Error()` via a small `errorMessage(err)` helper. Unblocks #7 (pflag) and #10 (cobra, which transitively bumps pflag).
2. `fmt.Errorf` literals on `expectedError`
Pre-existing pattern: `expectedError: fmt.Errorf("...%s...", flagName)`. Replaced with `errors.New("..." + flagName + "...")`. Same string semantics, no format-string indirection, and stays clean of Go 1.24's vet 'non-constant format string' check for future test churn.
3. gotestsum v1.12.0 doesn't build on Go 1.25
`go install gotest.tools/gotestsum@v1.12.0` pulls `golang.org/x/tools@v0.19.0`, which contains:
```
internal/tokeninternal/tokeninternal.go:64:9: invalid array length -delta * delta (constant -256 of type int64)
```
This compiles on Go 1.24 but not on Go 1.25. As soon as any dep bump pushes `go.mod` past `go 1.24.0` (PR #11 forces `go 1.25.0` via x/time v0.15+), the `Install gotestsum` step fails. Bump to gotestsum v1.13.0, which pulls newer x/tools that compiles on both 1.24 and 1.25.
Unblocks #11 (x/time) and any future bump that nudges the Go floor.
Verification
Locally on this branch:
After merge
Recreate the three open Dependabot PRs (`@dependabot recreate` on #7, #10, #11). All three should come back green.
Caveat on #11: it's not purely a library bump. `golang.org/x/time v0.15.0` requires `go 1.25.0` in go.mod, which cascades a Go-toolchain floor bump onto downstream consumers (same kind of cascade as #16's 1.18 → 1.24). Worth a separate sign-off before merging #11, even with this PR landed.
Test plan