Renovate: Bug: go.mod changes not comitted after "go mod tidy"

Created on 25 Apr 2019 · 4Comments · Source: renovatebot/renovate

After running "go get" and "go mod tidy", we currently don't check if "go.mod" itself has changed and commit those changes if so. i.e. the only changes we pick up are the ones we made ourselves.

gomod priority-2-important bug

Source

rarkins

All 4 comments

One problem I've realised with this is that this feature is kind of incompatible with our current behaviour/feature of stripping out relative replace statements in go.mod.

As requested by @felixfbecker in #2596 long ago, Renovate currently strips out relative replace statements before running go get. The problem then is that go mod tidy may update go.mod too. So then we have modifications to go.mod that we made, that are only meant to be temporary, and then modifications from go mod tidy that we should be detecting and committing. We definitely don't want to commit the removal of replace statements.

Possible ideas coming to mind:

If go get and go mod tidy could both support a flag like --ignore-replaces. I assume this is not possible!
Instead of deleting, maybe we comment out each line, enabling us to "uncomment" the line again later before checking if the file has been modified.

rarkins on 25 Apr 2019

Replaces are also used to replace a dependency with a fork. It's actually the only way to import github.com/docker/docker because all the various repos that have the contents of that package don't actually live at that path. Generally users will probably not want you to mess with replaces because they are few and I don't think there can be a good automated process to update them.

Anyway, you definitely can't ignore the replaces! The original issue was specifically about relative replaces pointing outside the repo. I think those should be the only kind that are ignored. For those ones, yes, they need to be brought back somehow at the end of the process. The comment method sounds reasonable.