Getting the New gomodTidyE Option Working as Expected

[jcburley]

Type of discussion.

I just want to chat

Tell us more.

This is a followup to: #19816 (comment)

I'm trying out the new gomodTidyE option in a local, private, repo, and see the -e option being passed to go mod tidy commands, but the end result is the same: go.mod is changed, but go.sum is not, resulting in CI build failures.

The log for an example of this behavior is here: https://app.renovatebot.com/dashboard#github/namely/thinkhr-sync/1004756954

Note that this might relate to an earlier discussion here: #19435

(I don't think I fully understand the issues discussed there, however.)

[rarkins]

Please past in here the log from when go mod tidy is run.

[jcburley]

@rarkins – is it possible run the go get command, ignoring the status of that command iff there's some "evidence" that it did actually download what was requested, and then running go mod tidy -e?

[rarkins]

Ultimately I'm not sure these commands would end up updating go.sum anyway?

[jcburley]

@rarkins – e.g. if a go.mod file is present, would it be reasonable to conclude that go get probably succeeded, despite returning a nonzero exit code?

(I'm not sure the answer is "yes"; this approach seems...unseemly.)

[jcburley]

Ultimately I'm not sure these commands would end up updating go.sum anyway?

For our repos (without the mocks/gen stuff checked in), I would think that if go mod tidy -e does get run even after go get fails as shown above, go.sum would be changed.

Our manual fix for the affected Renovate PRs (which fail due to only go.mod being modified) is to checkout the PR branch, go mod tidy -e, commit, and push the result.

That causes the PR to change both go.mod and go.sum, and fixes most, if not all, of those failing PRs.

It's those manual steps we're seeking to avoid.

What I don't understand is whether the point at which go mod tidy -e would/could be run (by Renovate) allows for including the go.sum changes, that would result, in the generated PR.

If the resulting changes aren't included in the PR, then this might well have been a wild-goose chase after all!?

[jcburley]

There are two other approaches worth considering, perhaps in combination:

1. Instead of editing go.mod directly, when any upgrade is deemed necessary, use go mod tidy -e to update it.
2. On our end, we could bite the bullet and check in our mocks/gen files to source control.

Item 1 might include consolidating all pending go.mod changes into a single PR that does go mod tidy -e. This might be useful when only the goModTidy (no -e) option is selected.

Item 2 is something we might look into; I think we do it on one or two Golang repos already, and while it'd make our repos larger, maybe it'd make enough other things (not just Renovate) easier to be worth the effort and change to our processes. I'll take it up with our team and see what they think.

[BirknerAlex]

I think I could reproduce this problem again on another repository.

As far I understand, I added the correct command with arguments to the execCommands commands array in my MR but since the first command get -d -t ./... fails with a non-zero exit code (which is expected in that case) the other commands are not executed here await exec(execCommands, execOptions); at all. It tells "go mod tidy command included" but never gets executed.

I think execOptions should receive a new option were we can specify allowedReturnCodes which is default [0] but should be able to get overridden on specific commands to prevent raising exceptions and stop executing the other commands in the execCommands array.

[vicentsegui]

For what is worth we have a similar setup (also generated go libraries for proto files by bazel not checked in) and the gomodtidyE function doesn't work because go get fails and aborts the run. Has there been any resolution to this issue?