fix(manager/gomod): perfer to use go version defined as toolchain to update artifacts

[trim21]

Changes

prefer use version from toolchain directive instead of go diective in go.mod, this will avoid change current toolchain directive.

Context

As explained in #34563, when running go get ./..., go will update toolchain directive in go.mod, which is a depType=toolchain change instead of expected depType=require change.

And there are 2 ways to avoid change of toolchain directive.

I don't think old version of go support go get ./... toolchain@${current toolchain} (just like we still didn't remove -d flag here), so it would be more backward compatible to just use version of current toolchain to avoid this.

If go.mod doesn't have such directive, we still use version frmo go directive.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Need to consider the edge case where the toolchain version is being upgraded in the same PR

[trim21]

So I think in that case we do not parse GoConstraints but use updated toolchain version from updatedDeps?

[rarkins]

Yes first check would be if Go is being updated in updatedDeps. There could also be some weird things like go mod directive updated but go toolchsin not.

[trim21]

Is it possible to update go.mod first then get constraints? this should avoid this problem naturally

[rarkins]

By default renovate doesn't bump the go.mod directive. This was the recommendation/request of the golang team. So 99% of the time it's probably only the tool chain getting bumped, or none. I agree with you that we shouldn't "accidentally" bump the tool chain by running a latest go

[viceice]

I think we simply need to use new file content to extract this information instead of reading old file from disk here.

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

Line 194 in ad5d318

config.constraints?.go ?? (await getGoConstraints(goModFileName));

[trim21]

I think we simply need to use new file content to extract this information instead of reading old file from disk here.

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

Line 194 in ad5d318

config.constraints?.go ?? (await getGoConstraints(goModFileName));

Yes, this is what I suggest

[trim21]

By default renovate doesn't bump the go.mod directive. This was the recommendation/request of the golang team. So 99% of the time it's probably only the tool chain getting bumped, or none. I agree with you that we shouldn't "accidentally" bump the tool chain by running a latest go

I don't mean go directive, I mean we update go.mod first then parse toolchain directive from go.mod ( like this PR already did).

In that case if we need to update toolchain directive, we get updated toolchain directive.

I don't know if it's possible.

[trim21]

it should be something like this?

  const goConstraints =
    config.constraints?.go ?? getGoConstraints(massagedGoMod);

[rarkins]

Yes. Any updates to go.mod would have been written out already