dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.67k stars 1.01k forks source link

GO Modules Proxy support #7362

Open owenhaynes opened 1 year ago

owenhaynes commented 1 year ago

Is there an existing issue for this?

Feature description

JFrog, GCP Artificat registry all provide ways for private go modules. Currently the Dependabot docs say that private registries are supported but no corresponding documentation is available.

Private go modules registries can be use in all sorts of way especially for code generation pipelines.

Currently dependabot fails because it can not resolve the packages for example generated.internal/foo

so we need a way of providing GOPROXY and GONOSUMDB to dependabot.

I seen past issues about GOPRIVATE but all seem to lead to dead ends.

image

jurre commented 1 year ago

Thanks for opening. The current support assumes using private (git) repositories, but we don't currently have great support for private module proxies. We're tracking this internally, but there isn't a public facing issue. I'll link this to our internal issue 👍

kurtmc commented 1 year ago

How is no one using dependabot and artifactory? @jurre Can we get a timeline for implementing the ability to set GOPROXY?

kurtmc commented 1 year ago

@jurre Any update on this?

abscondment commented 7 months ago

Bump on this :)

Our use case: our applications use a mixture of public and private go modules. The private ones are hosted in an internal Github Enterprise (git.example.com). The public ones are hosted by the usual suspects (github.com, golang.org, gopkg.in, etc).

To insulate our build pipeline from public modules becoming unavailable, we proxy all dependencies through a nexus repository.

All our build environments need configuration like this to go mod * successfully:

go env -w GOPROXY=https://nexus.example.com/repository/goproxy/
go env -w GONOPROXY=none
go env -w GONOSUMDB="*.example.com"

Dependabot is missing both of our goals here: it can't find the private modules hosted on git.example.com, and it isn't accessing the public modules through our proxy. The first issue is the real blocker, but solving it correctly would also resolve the second issue.

bgentry commented 2 months ago

@jonjanego if I can be of any help testing a solution here (no matter how beta it is), please let me know. I recently launched River Pro which is installable as a private Go module using GOPROXY and GONOSUMDB envs. I have multiple private repos using this dependency where I'd like to set up Dependabot, but can't because it's unable to access a private or custom GOPROXY server.

This also doesn't just affect me, it affects any customers of River Pro (there are already several, all of which are GitHub customers too).

Excited to see this soon :pray:

promiseofcake commented 1 month ago

This is also important to us.