Go Modules: update import paths after major upgrades

[rarkins]

Suggestion:

@rarkins But there is a section about updating dependencies; see https://github.com/marwan-at-work/mod#upgrading-a-dependency . Also according to official go mod docs you are supposed to update your import paths when increasing major version (from v2 and onward, see https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher) and renovate doesn't cover this currently. Renovate fails to upgrade for example caarlos0/env because of missing major version in imports, see caarlos0/env#86. marwan-at-work/mod seems to be a nice fit to automatically fix the import paths for major versions updates. Not sure whether it fixes also this issue but given it is a recommended tool by official documentation I would expect it to work correctly.

Originally posted by @rkuska in #3557 (comment)

[Hexcles]

IIUC, without this, major upgrades to v2+ are completely broken for Golang in Renovate if the code has explicitly included version numbers in import paths.

e.g. our codebase has

https://github.com/web-platform-tests/wpt.fyi/blob/446d5d8e21905a1c66b0468bc7780ad79eb15873/api/taskcluster/webhook.go#L20

Renovate creates this PR for us: web-platform-tests/wpt.fyi#1550

which does not work at all.

Running go build will add v20 back to go.mod and v21 isn't imported at all. In fact, running go mod tidy will remove v21 altogether as it's not used. (There might be another bug here: I enabled gomodTidy but it doesn't seem to take effect.)

[rarkins]

@Hexcles are you aware of any existing tools/commands that could achieve this today as a post install step? Or fool-proof logic for updating .go files that Renovate could implement natively?

Of course the next challenge is that even with updated import paths, you’re probably still “broken” due to breaking change itself.

[Hexcles]

I tried marwan-at-work/mod to no avail. psampaz/go-mod-outdated also doesn't list available major upgrades. I can't find an automated solution so far and am quite surprised by that...

I think the right thing to do here is to accept the fact that we can't automatically upgrade major versions for Go modules yet and stop creating those no-op PRs that only touch go.mod.

[Hexcles]

FWIW, Dependabot has the same limitation: https://dependabot.com/blog/go-modules-alpha/

[rarkins]

@Hexcles you can disable major updates for go modules this way in config:

  "gomod": {
    "major": {
      "enabled": false
    }
  }

Although I suggest instead putting them behind an approval step so they're not completely "out of sight out of mind".

  "masterIssue": true,
  "gomod": {
    "major": {
      "masterIssueApproval": true
    }
  }

The PRs currently aren't "no-op" in the sense that they do update the go.mod file, and for many projects it's important to be aware that a major update is available, even if the PR itself isn't mergeable. In pretty much every language that uses semver, it's often the case that the PR that Renovate raises is "broken" and requires human updates on top, but that's no reason to disable them by default - people should be aware when there's a major update available.

And it goes without saying that the second there's a third party tool that can update the imports, or a foolproof way we can do it ourselves, then we can add it. Unlike Dependabot, we operate on a shallow clone of repos so we already can do things like go get, go mod vendor and go mod tidy.

[Clivern]

I have seen this case when renovate did upgrade from github.com/logrusorgru/aurora to github.com/logrusorgru/aurora/v3. there is a tool in go that can update the import path for all go files. it is pretty much like sed but only to update go source code.

Something like this will update all import paths to /v3.

$  gofmt -w -r '"github.com/logrusorgru/aurora" -> "github.com/logrusorgru/aurora/v3"' ./

https://golang.org/cmd/gofmt/

But i agree that manual intervention still recommended since that way of versioning was to clearly say that it is a major release and won't / may not be a backward-compatible especially if there no proper automated testing.

[viceice]

Duplicate of #3348