Jamie Tanna
826541b266
Previously, we were caching private Go modules' information, even when `cachePrivatePackages=false`. This leads to the module path, versions, and possibly the `go` directive being cached unintentionally. Instead of doing so, we should make sure that we're intentionally caching packages. To do this, we can use a mix of the `GOPRIVATE`/`GONOPROXY` to determine which packages shouldn't be fetched in the public Go proxy, given they're private, following how the Go toolchain itself does this. When interacting with the public Go proxy, we treat these packages as public (as the public Go proxy has no means to authenticate) and so anything outside of this should be treated as private. When `GOPROXY` contains `direct`, we only treat a package as public only when the public proxy is in the list too, the way Go's own default is written. This is used to imply that `direct` is the fallback for whatever the public proxy doesn't have. When thre is no Go proxy set, `GOPROXY=direct` means everything comes from source, which tells us nothing about who is allowed to read it. This doesn't catch everything: with the default `GOPROXY`, a private package the public proxy doesn't have falls through to `direct` and is still cached by Renovate, unless `GOPRIVATE` says otherwise. We only learn that no proxy served it after we've fetched it, which is after `cacheable` is determined. When using Renovate with a private Go proxy mirror, such as Artifactory, this will result in no cached packages until `cachePrivatePackages: true` is set. This is a similar change to #45348. Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
The best way to lookup Go Modules is using Go proxies.
GOPROXY settings
This datasource will use default GOPROXY settings of https://proxy.golang.org,direct if the environment variable is unset.
To override this default and use a different proxy in self-hosted environments, configure GOPROXY to an alternative setting in env.
To override this default and stop using any proxy at all, set GOPROXY to the value direct.
Pseudo versions
Go proxies return an empty list of versions when queried (@v/list) for a package which uses pseudo versions, but return the latest pseudo-version when queried for @latest.
If the @latest endpoint returns a pseudo-version, and the release list is empty, then this datasource will return the latest pseudo-version as the only release/version for the package.
Checking for new major releases
When a Go proxy is queried for @v/list it returns only versions for v0 or v1 of a package.
Therefore Renovate will also query @v2/list just in case there also exists a v2 of the package.
Similarly, if the dependency is already on a higher version such as v5, Renovate will check in case higher major versions exist.
You do not need to be worried about any 403/404 responses which result from such checks - they are the only way for Renovate to know if newer major releases exist.
Release timestamps
A Go proxy reports the commit time of the tagged commit as a version's Time, which can be different to when the release first existed.
This inconsistency can lead to minimumReleaseAge being applied incorrectly to the Go module's updates.
!!! note
For modules hosted on GitHub, Renovate will look up if there is a GitHub Release on the repository, and if so, use the Release's publication time, if it's later than the timestamp reported by the Go proxy.
This lookup needs a GitHub token to be configured, and is skipped if the lookup fails, leaving the timestamp reported by the Go proxy in place.
For example, this happens when:
- an infrequently updated repository prepares a GitHub Release by creating a draft release
- some time passes, and the maintainers publish the Release
- no new commits are pushed to the release branch (i.e.
main) in that time
Fallback to direct lookups
If no result is found from Go proxy lookups then Renovate will fall back to direct lookups.