Dependabot-core: Private Module Golang

[renanbastos93]

I have module private on Golang inside my organization so dependabot not found it to validate.

my file:

version: 2
updates:

  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      # Check for updates managed by Composer once a week
      interval: "weekly"

  # Maintain dependencies for Golang
  - package-ecosystem: "gomod"
    directory: "/"
    schedule:
      # Check for updates managed by Composer once a week
      interval: "weekly"

[jurre]

The github native version of dependabot does not yet support private packages. We recommend to use dependabot.com in the meanwhile.

We do plan to support private registries / packages but don't have a timeline for where it will land currently.

[renanbastos93]

The github native version of dependabot does not yet support private packages. We recommend to use dependabot.com in the meanwhile.

We do plan to support private registries / packages but don't have a timeline for where it will land currently.

Hi, @jurre thanks for explaining to me.

Can I help the project? I would like a lot that Dependabot having the support of private modules.

In Github Actions, I used this line

git config --global url."https://${{ secrets.GLOBAL_TOKEN }}:[email protected]/myorg".insteadOf "https://github.com/myorg"

[jurre]

Can I help the project?

Unfortunately not, the part that we still need to implement is not open source.

[renanbastos93]

Can I help the project?

Unfortunately not, the part that we still need to implement is not open source.

Maybe, I did think some like this a parameter in YAML.
e.g

go_private: "https://github.com/myorg/project"

internal code it adds this var env

GOPRIVATE=go_private

etc...

What do think about it?

[jurre]

dependabot-core does support it, but our internal systems that run dependabot don't yet.

You can use https://dependabot.com for now and once we add support for it in the github native version I'll make sure to check back here

[tdi]

I would be also interested in this highly - having close to 20 big monorepos in go here:)

[tdi]

@jurre for me it would be sufficient even if dependabot skipped the modules that are private and just show updates for the public ones. Go mod fails completely even if one module is private and not in google's proxy.

[jurre]

Yeah I understand, eagerly waiting for this feature to land myself as well. I would recommend to use https://dependabot.com for now, we'll provide an easy upgrade path once the feature lands in github natively.

[renanbastos93]

I would be also interested in this highly - having close to 20 big monorepos in go here:)

me too so here I have 7 big monorepos

[torstenwalter]

Any update on this? Just ignoring private repositories would unblock many users from using it.

[jpopadak]

It would be wonderful if we could add other GO* variables. For example, we have internal code repos not in GitHub, and they get published to an externally available GOPROXY instance. But, we need to set a few, GOPROXY and GONOSUMDB.

[ivanpk]

+1 to even having private repos simply ignored as a workaround, instead of complete failure.

[jurre]

Ignoring a private dependency is unfortunately not an option, as we shell out to go get etc, and those fail if any of the dependencies can not be resolved.

This is definitely on our radar though, and I hope to be able to share more about it soon

[torstenwalter]

If there would be an option to specify which are the private modules it should be possible to remove them from go.mod file and thus ignore them.

[jurre]

I'm fairly sure go mod tidy will fail in that case? We also don't currently have that data available when we run an update job in dependabot-core, so we'd have to change the interface and how we use dependabot-core. I'm sure there is a way to do it, but I don't think it'll be trivial. And since we have limited capacity, we'd rather spend that time on supporting private packages properly. It's a priority for us in general so it's definitely coming.

I can see how having the option to completely ignore a dependency and also not provide access to it could also be useful, but currently I think we'd have to juggle around quite a few things around to make it work for go mod.

[ivanpk]

And since we have limited capacity, we'd rather spend that time on supporting private packages properly. It's a priority for us in general so it's definitely coming.

Is there any update on a rough timeline, etc that this support might be available?

[torstenwalter]

According to https://github.blog/changelog/2020-12-02-dependabot-version-updates-from-private-github-repositories/ and https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates#package-ecosystem it is now supported.

[jpopadak]

@torstenwalter I still dont think this would solve my use case. 😞

We have other modules that exist in and outside of GitHub (and outside of the same GitHub Org). To pull those, we set GOPROXY and GONOSUMDB to retrieve the modules to build.

Almost wondering if I should open a separate ticket just for GOPROXY / GONOSUMDB as this ticket is mostly focused on private repos within the same GitHub Organization. 🤔

[jurre]

@torstenwalter I still dont think this would solve my use case. 😞

We have other modules that exist in and outside of GitHub (and outside of the same GitHub Org). To pull those, we set GOPROXY and GONOSUMDB to retrieve the modules to build.

Almost wondering if I should open a separate ticket just for GOPROXY / GONOSUMDB as this ticket is mostly focused on private repos within the same GitHub Organization. 🤔

It's coming, but if you need this right now I'd recommend using dependabot-preview via https://dependabot.com