mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-25 15:01:49 +00:00
Jamie Tanna
0876273a37
* feat(datasource/go): look up modules from a `go-import` `mod` proxy
When interacting with a Go module, a host can advertise that a module is
served by a Go module proxy, instead of a Version Control System (VCS),
by noting the following in the `go-import` HTML meta tag:
<meta name="go-import" content="bsr.example.com/gen/go mod https://bsr.example.com/gen/go">
Previously, we only handled the `git` protocol, which would lead to
users integrating with a (private) Buf Schema Registry (BSR) not being
able to download generated Go modules.
When interacting with public Go modules on `buf.build`, these are served
successfully through `proxy.golang.org`, but a private BSR can't be
routed through the public proxy, and therefore fail to be looked up.
We should instead follow how `go` does it[0] and add support for
directly calling a `mod` proxy.
We leverage `getDirectReleases()`s' checks to make sure we don't
try and follow this flow when we're on a "known" host, i.e. if we're
pulling a module called `github.com/...` or a vanity domain package name
that resolves to `gitlab.com`.
The `?go-get=1` will keep the in-memory HTTP cache's result.
[0]: https://go.dev/ref/mod#serving-from-proxy
Co-Authored-By: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
Co-Authored-By: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
---------
Co-authored-by: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>