Skip to content

chore: bump go-types to v0.0.0-20260902160716-5c6c50f32fcd - #12

Merged
ungerik merged 2 commits into
mainfrom
chore/bump-go-types
Sep 2, 2026
Merged

chore: bump go-types to v0.0.0-20260902160716-5c6c50f32fcd#12
ungerik merged 2 commits into
mainfrom
chore/bump-go-types

Conversation

@ungerik

@ungerik ungerik commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Bumps github.com/domonda/go-types in htmlform from v0.0.0-20251017132438-6b9580b458e1 to v0.0.0-20260902160716-5c6c50f32fcd (latest).

Commit 1 — the bump

  • go directive 1.25.0 -> 1.26.0 in htmlform, because the new go-types declares go 1.26.0. go.work follows.
  • Only other transitive change: go-isatty v0.0.20 -> v0.0.22. No other module in the workspace requires go-types directly.

Commit 2 — the CI job

Raising the go directive 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}}' -m straight into xargs. 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: go.work requires go >= 1.25.0 (running go 1.24.13; GOTOOLCHAIN=local), xargs got empty input, and Build / Vet / Test / Gosec all reported success having compiled zero packages. You can see it in the last green run on main: 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:

  • The tools module has no packages of its own — it holds only a tool directive. go vet, go test and gosec all treat a pattern matching no packages as an error, so those steps now 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, giving cannot use orderedmap.New[...] in schemautil.go. Raised to v1.69.0 in tools/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.

…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
ungerik force-pushed the chore/bump-go-types branch from 21046e4 to 9bbf015 Compare September 2, 2026 16:27
@ungerik
ungerik merged commit efc3b03 into main Sep 2, 2026
3 checks passed
@ungerik
ungerik deleted the chore/bump-go-types branch September 2, 2026 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant