build: Bump dependencies

[gonmmarques]

References

See #39

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[mathieu-lemay]

For what it's worth, this looks perfectly fine to me. My only "concern" would be the bump of the Go version itself, I personally think it's fine.

[mathieu-lemay]

This is the only thing I can see as problematic with this change, it now requires go 1.24. I personally don't mind, but I'm not sure what version of go do the owners of the project want to target.

[gonmmarques]

That is understandable, my initial worry was about testcontainers dependency that is very outdated and has CVEs. I ended up bumping more things, with a worry that this would again not be bumped for some time. But for me is also fine if we keep Go version as is and just try to bump testcontainers.

[leeturner]

Hi, I have approved the workflow runs and it looks like we have some linting errors. Are those something you want to address before we merge?

Error: client.go:41:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()
  	                    ^
  Error: client.go:66:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()
  	                    ^
  Error: client.go:81:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()

[gonmmarques]

Hi, I have approved the workflow runs and it looks like we have some linting errors. Are those something you want to address before we merge?

Error: client.go:41:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()
  	                    ^
  Error: client.go:66:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()
  	                    ^
  Error: client.go:81:22: Error return value of `res.Body.Close` is not checked (errcheck)
  	defer res.Body.Close()

Hello, thanks for allowing the workflow to run. I can try to fix the lint, but what would be your input/suggestion here?

a) Basically ignore close errors via

defer func() {
    _ = res.Body.Close()
}()

Simplest approach, but discards potentially useful error information.

b) Capture close errors in return value

defer func() {
		cerr := res.Body.Close()
		if err == nil {
			err = cerr
		}
	}()

Requires changing all function signatures to use named return values. Returns close errors only when the main operation succeeded.

c) Any other option, e.g. just logging the error

Would require adding a logging dependency (I don't see any logger currently used in the project).

[mathieu-lemay]

If I may chime in, those "errors" were already present, the only change is that they are now reported by the linter, I assume because golangci-lint was updated. I consider them very harmless in the sense that there's nothing really actionnable on a body close error, except logging it and carrying on.

In my team at work, we usually silence them:

defer res.Body.Close() //nolint:errcheck // there is nothing to do even if an error occurs on close function

If we don't want to do that, then I'd go with option c proposed by @gonmmarques, using either of Go's builtin loggers (log or log/slog).

[gonmmarques]

If I may chime in, those "errors" were already present, the only change is that they are now reported by the linter, I assume because golangci-lint was updated. I consider them very harmless in the sense that there's nothing really actionnable on a body close error, except logging it and carrying on.

In my team at work, we usually silence them:

defer res.Body.Close() //nolint:errcheck // there is nothing to do even if an error occurs on close function

If we don't want to do that, then I'd go with option c proposed by @gonmmarques, using either of Go's builtin loggers (log or log/slog).

Yup, exactly those "errors" were indeed already there and with the update I did on the linter, it now complains about them. Since I saw them already there was in doubt what the preferred approach was.
To me that is also clear, if they are consideres harmless, so I committed with that approach. Thanks

[mathieu-lemay]

I was just looking at the code and noticed this. It makes me happy to see it fixed 😄

[leeturner]

If everyone is happy with this I can merge it in

[leeturner]

Thank you all for helping get this merged

[gonmmarques]

Thanks for reviewing and merging. Can this be released?

[walkerus]

I'll release a new version today