Renovate: Support Golang

[rarkins]

This issue is for building up (a) support (please +1 if you would like to see Go support) and (b) requirements, e.g. helping suggest what scope is required and what APIs can be used.

[RXminuS]

At the moment go-dep and accompanying lock files are a popular way of vendoring dependencies but with go 1.10 there is now also a fork that will be the "ideomatic" way of managing dependencies.

[joseSantacruz]

any update on this request

[rarkins]

No, but as soon as there’s some input on this it is more likely to start:

what scope is required and what APIs can be used.

[mxey]

Go 1.11 (RC at the moment) adds preliminary module support that will become final in 1.12. See https://tip.golang.org/cmd/go/#hdr-Defining_a_module for how a module and its dependency spec is made up.

[petemounce]

+1; we currently use https://golang.github.io/dep/ .
We might swap to vgo or bazel with go 1.11.

We use Bazel for most of our builds of other languages (Java, Scala, web things, C*).

[mxey]

The best implementation might be to wait for #2323 and then use "go get" to update the dependencies. https://tip.golang.org/cmd/go/#hdr-Module_queries

[mxey]

@petemounce Renovate already has some support for Bazel, which would have to be extended for Go-specific rules: https://github.com/renovatebot/renovate/tree/master/lib/manager/bazel

[felixfbecker]

We now use Go modules (the new _official_ Go module system) at Sourcegraph so this would be very helpful to us.

[felixfbecker]

In particular, we would like to group both npm updates to a specific package and Go updates to a specific module together. This should be possible with the grouping feature and package rules, but the Go modules support is the missing piece, so at the moment we cannot use Renovate even for the npm update (because it would not be grouped) and have to write our own thing to do it :/

[rarkins]

@felixfbecker would you be able to create a reference repo that I can clone/fork to use for testing?

[nicksnyder]

Here are some examples of open source Go repos that use modules:

• https://github.com/gohugoio/hugo
• https://github.com/jesseduffield/lazygit
• https://github.com/gin-gonic/gin/

[felixfbecker]

@rarkins here is a minimal example repo: https://github.com/nicksnyder/renovate-dependency-test

It also includes an npm dependency and a theoretical Renovate config to group the packages.

[rarkins]

@felixfbecker so is "vendoring" of dependencies a mandatory requirement too?

[nicksnyder]

For Go, some projects (2 out of the 3 I shared above) choose to vendor dependencies. If renovate updates one of those vendored dependencies, I would expect the vendor folder to be updated as well.

[rarkins]

@nicksnyder thanks, understood. In your (sourcegraph's) case, would you consider a non-vendored solution initially (i.e. you'd need to remove vendor/ probably) or is any solution useless for you until it supports vendoring?

Simple updating the go.mod using Renovate looks like something that could be done within a day's work, unless I'm missing something. But adding vendoring is a whole other - complex - challenge, because it's not supported for any language so far. So I'm trying to evaluate whether to deliver non-vendoring support initially or if that's pointless. Sounds though that some projects use non-vendoring, so wouldn't be entirely pointless.

[nicksnyder]

I think it would be perfectly reasonable and useful to deliver a solution that works for Go projects that don't vendor.

I am unsure if we could get away with not vendoring ourselves. @slimsag can you comment on this?

[calebcartwright]

I second the notion that there's value in a solution even if it doesn't initially support vendoring

[rarkins]

Thanks everyone for the feedback

[slimsag]

I am unsure if we could get away with not vendoring ourselves. @slimsag can you comment on this?

I believe we can sometime soon, yes.

@rarkins I should also mention that also go.sum needs to be updated (similar to package-lock.json in npm).

[rarkins]

@slimsag thanks for the clarification. This part should also not be a big problem because we do various "checksum"/"lock file" calculations already too. Adding this URL for reference: https://tip.golang.org/cmd/go/#hdr-Module_downloading_and_verification

[kevinburke]

golang.org/x/build uses Go modules

[rarkins]

Can anyone confirm that go mod tidy would be the correct and most efficient command to run in order to update go.sum once go.mod is updated?

Important: ideally we have a command that updates go.sum based on go.mod only. I think go mod tidy requires full access to source code in order to scan it and check that go.mod itself is correct. In cases like Renovate updating a version, which would be an unnecessary step so ideally I'm looking for a command that simply recalculates go.sum based on go.mod as the only input.

[rarkins]

Code for the first two steps (go.mod and go.sum updating) is functionally complete - just needs more testing. I expect this can be released in the next week, and I'll look into vendoring afterwards.

[renovate-bot]

:tada: This issue has been resolved in version 13.87.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[rarkins]

Initial support for Go Modules has landed in [email protected], which will be live in the app later today.

I will leave this feature/language disabled by default until I get a solid "thumbs up" from someone who can verify that it's working as expected, after that it will be on by default for everyone who has a go.mod file in their repo.

To manually enable support now, you need to add the preset ":gomod" to your Renovate config. If you have a repo with only go modules (i.e. no other package managers that Renovate supports) then you won't get a "Configure Renovate" PR and need to add the renovate.json manually to activate the app.