build: pin oapi-gen until toolbox gets 1.21.13

[lzap]

Unsure how to implement pinning effectively for vendored projects. What I usually do is manually go get those libraries in a prepare script or Makefile.

[croissanne]

How about pinning it in the files which have the directive ?

git grep -l 'github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen' | xargs sed -i 's|github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen|github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@v2.4.0|g'

or

git grep -l 'github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen' | xargs sed -i 's|github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen|github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@v2.3.0|g'

[lzap]

For the record the problem is auto-updating of dependencies:

+ /home/runner/go/bin/go1.21.9 generate -mod=mod ./...
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: downloading github.com/oapi-codegen/oapi-codegen/v2 v2.4.0
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: toolchain upgrade needed to resolve github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: github.com/oapi-codegen/oapi-codegen/v2@v2.4.0 requires go >= 1.[21](https://github.com/osbuild/image-builder/actions/runs/11012206487/job/30577910838?pr=1350#step:5:22).13 (running go 1.21.9; ../../../go.mod sets toolchain go1.21.9)
internal/clients/composer/package.go:1: running "go": exit status 1
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: toolchain upgrade needed to resolve github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: github.com/oapi-codegen/oapi-codegen/v2@v2.4.0 requires go >= 1.21.13 (running go 1.21.9; ../../../go.mod sets toolchain go1.21.9)
internal/clients/content_sources/package.go:1: running "go": exit status 1
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: toolchain upgrade needed to resolve github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: github.com/oapi-codegen/oapi-codegen/v2@v2.4.0 requires go >= 1.21.13 (running go 1.21.9; ../../../go.mod sets toolchain go1.21.9)
internal/clients/provisioning/package.go:1: running "go": exit status 1
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: toolchain upgrade needed to resolve github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: github.com/oapi-codegen/oapi-codegen/v2@v2.4.0 requires go >= 1.21.13 (running go 1.21.9; ../../../go.mod sets toolchain go1.21.9)
internal/clients/recommendations/package.go:1: running "go": exit status 1
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: finding module for package github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: toolchain upgrade needed to resolve github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
go: github.com/oapi-codegen/oapi-codegen/v2@v2.4.0 requires go >= 1.21.13 (running go 1.21.9; ../../go.mod sets toolchain go1.21.9)
internal/v1/server.go:1: running "go": exit status 1

Asked on Slack and got few recommendations and an article link which I am going to read in a bit. A recommendation was to use GOTOOLCHAIN=auto option. Need to learn about this.

[lzap]

Slightly tuned the sed hack but this will do I guess.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Files with missing lines	Coverage Δ
internal/v1/server.go	76.69% <ø> (ø)

[lzap]

Okay messed up sed, should be correct this time.

[ondrejbudai]

dumb question: Why cannot we use Go 1.21.13?

[ondrejbudai]

Ah, is that because registry.access.redhat.com/ubi9/go-toolset has not been rebuilt yet? Go 1.21.13 is already in repositories, so we should be able to just dnf upgrade -y golang in the container. (it's needed to do some USER dancing because the default user is not root)

[ezr-ondrej]

dumb question: Why cannot we use Go 1.21.13?

https://github.com/osbuild/image-builder/pull/1349 failed to do it easily

[ezr-ondrej]

Looks :green_apple: to me :shrug:

[lzap]

Exactly, the thing is some go tools now tries to upgrade to latest version which is causing the issue. Namely go generate here but it is a common problem across tools from 1.21+.

Tests are green.

[ezr-ondrej]

I see no objections, lets get it in :)

[jamietanna]

Apologies for this! https://github.com/oapi-codegen/oapi-codegen/releases/tag/v2.4.1 should now resolve this for y'all :crossed_fingers:

[lzap]

Jeeeez Jamie, no need to apologize. Thank you for your help on the Go Slack channel and for your hard work on this project, and many more!

Let’s revert the hack (or keep it): https://github.com/osbuild/image-builder/pull/1355