chore: bump go-types to v0.0.0-20260902160716-5c6c50f32fcd - #12
Merged
Conversation
…50f32fcd go-types now declares go 1.26.0, so htmlform's go directive moves 1.25.0 => 1.26.0, the go.work directive follows, and the CI job has to set up a matching toolchain instead of 1.24.
Bumping the toolchain to 1.26 is the first time this job runs at all.
Every step piped `go list -f '{{.Dir}}' -m` straight into xargs, and a
pipeline's exit status is xargs', not `go list`'s -- so once go.work
required go 1.25 while the job set up go 1.24, `go list` failed with
"go.work requires go >= 1.25.0", xargs got empty input, and Build, Vet,
Test and Gosec all reported success without touching a single package.
Write the module list to a file once and fail the job if it is empty.
With the steps running for real, two things needed fixing:
- The tools module holds only a `tool` directive and no packages of its
own. `go vet`, `go test` and gosec all treat a pattern matching no
packages as an error, so skip modules with nothing to check. `go build`
only warns, so Build still takes the whole list.
- gosec failed to build: go.work unifies the dependency graph, so the
go-types bump raised invopop/jsonschema to v0.14.0 for the tools module
too, and v0.14.0 swapped wk8/go-ordered-map for pb33f/ordered-map.
anthropic-sdk-go v1.38.0 still expected the wk8 type. Raising it to
v1.69.0 in tools/go.mod resolves the conflict.
ungerik
force-pushed
the
chore/bump-go-types
branch
from
September 2, 2026 16:27
21046e4 to
9bbf015
Compare
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.
Bumps
github.com/domonda/go-typesinhtmlformfromv0.0.0-20251017132438-6b9580b458e1tov0.0.0-20260902160716-5c6c50f32fcd(latest).Commit 1 — the bump
godirective1.25.0->1.26.0inhtmlform, because the new go-types declaresgo 1.26.0.go.workfollows.v0.0.20->v0.0.22. No other module in the workspace requires go-types directly.Commit 2 — the CI job
Raising the
godirective means the workflow has to set up a matching toolchain (1.24->1.26.5). That turned out to be the first time this job runs at all.The workflow was passing without checking anything. Every step piped
go list -f '{{.Dir}}' -mstraight intoxargs. A pipeline's exit status isxargs', notgo list's — so oncego.workrequired go 1.25 while the job set up go 1.24,go listfailed withgo: go.work requires go >= 1.25.0 (running go 1.24.13; GOTOOLCHAIN=local),xargsgot empty input, and Build / Vet / Test / Gosec all reported success having compiled zero packages. You can see it in the last green run onmain: run 33611291582 prints that error under all four steps. The module list is now written to a file once, and an empty list fails the job.With the steps running for real, two things needed fixing:
toolsmodule has no packages of its own — it holds only atooldirective.go vet,go testand gosec all treat a pattern matching no packages as an error, so those steps now skip modules with nothing to check.go buildonly warns, so Build still takes the whole list.go.workunifies the dependency graph, so the go-types bump raisedinvopop/jsonschematov0.14.0for thetoolsmodule too, and v0.14.0 swappedwk8/go-ordered-mapforpb33f/ordered-map.anthropic-sdk-go v1.38.0still expected the wk8 type, givingcannot use orderedmap.New[...]inschemautil.go. Raised tov1.69.0intools/go.mod.Verification
Ran the workflow's List / Build / Vet / Test / Gosec commands locally against this branch — all pass, and Gosec reports 0 issues over the 52 files it now actually analyzes.