Run go mod tidy in subdirectories

[gnuletik]

What would you like Renovate to be able to do?

When repo has the following architecture:
go.mod

module root

go 1.19

require (
  google.golang.org/x/text v0.4.0
)

cmd/example/go.mod

go 1.19

replace root -> ../../

require (
  root v0.0.0-00010101000000-000000000000
)

require (
  golang.org/x/text v0.4.0 // indirect
)

go.sum files are omitted here.

Reproduction repo here: https://github.com/gnuletik/renovate-repro-19270
Failing renovate PR: gnuletik/renovate-repro-19270#1

In a scenario where:

• golang.org/x/text should be updated from v0.4.0 to v0.5.0
• with a renovate.json with "postUpdateOptions": ["gomodTidy"]

Renovate creates a PR which updates go.mod and go.sum files at the repository root.
However, this breaks the cmd/example package which also needs to be updated to v0.5.0 (in the indirect dependencies part).

Note: This issue only occurs for indirect dependencies upgrade.

If you have any ideas on how this should be implemented, please tell us here.

Could go mod tidy be executed in every sub-packages in the repo?

Is this a feature you are interested in implementing yourself?

Yes

[rarkins]

I think that running go mod tidy in every sub package is not ideal because it could end up updating unrelated go.sum files. Instead, the solution should ideally understand which sub-packages are dependent and instead update only those ones (e.g. by linking root to root in the above example).

[github-actions]

Hi there,

Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction.

We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[viceice]

I think that running go mod tidy in every sub package is not ideal because it could end up updating unrelated go.sum files. Instead, the solution should ideally understand which sub-packages are dependent and instead update only those ones (e.g. by linking root to root in the above example).

We can probably use a similar approach like in nuget manager.

[gnuletik]

Thanks for the fast feedback!

Here is a reproduction repository with a failing PR created by renovate: gnuletik/renovate-repro-19270#1

[rarkins]

Reproduction forked to https://github.com/renovate-reproductions/19270

[rarkins]

Ideal solution: build a dependency graph between the go.mod files/directories and then run in dependent ones only.

Pragmatic alternative solution: a new option goModTidyAll which runs go mod tidy in every package in a repo whenever any dependency is updated

[gnuletik]

Other possible simple solution: run renovate on indirect dependencies too.

Those lines are currently ignored here:


renovate/lib/modules/manager/gomod/extract.ts

Line 73 in 0f2eb5d

if (requireMatch && !line.endsWith('// indirect')) {

renovate/lib/modules/manager/gomod/extract.ts

Line 125 in 0f2eb5d

if (multiMatch && !line.endsWith('// indirect')) {

We could add a new option goModIndirect which updates indirect dependencies too.

What do you think about this @rarkins ?

[rarkins]

I thought we maybe had an open issue already about updating indirect dependencies, but I can't find it.

However I found #12999, and it looks like we could combine/close this issue as a duplicate?

[rarkins]

I agree on the idea of indirect though. I think we should include such dependencies in what we extract, but mark them as depType=indirect, enabled=false. That way you can add a package rule with matchManagers=gomod, matchDepTypes=indirect, enabled=true which then overrides the default approach.

[gnuletik]

Thanks for the feedback ! Definitely agree to close this issue as a duplicate then 👍

[rarkins]

Duplicate of #12999