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

[casaqori]

I see, seemingly there is a typo in your observations. Lets clarify:

For go.mod:

go 1.23.5

renovate now pick go1.22.5 go1.23.5, and go won't add toolchain directive.

That will satisfy my ask to pin the toolchain at a specific version. In this case its implicitly specified by the go directive.

@trim21 I had observed that if renovate makes upgrades because of known CVEs in dependencies, it would ignore the go directive at all, and even upgrade. e.g. go1.22.0 to go1.22.13 and toolchain to go1.24.1 with this config:

  "vulnerabilityAlerts": {
    "enabled": true
  },

Might be unrelated to this PR, just giving a heads-up.

[trim21]

I see, seemingly there is a typo in your observations. Lets clarify:

For go.mod:

go 1.23.5

renovate now pick go1.22.5 go1.23.5, and go won't add toolchain directive.

That will satisfy my ask to pin the toolchain at a specific version. In this case its implicitly specified by the go directive.

thanks, it's indeed a typo

[trim21]

I see, seemingly there is a typo in your observations. Lets clarify:

For go.mod:

go 1.23.5

renovate now pick go1.22.5 go1.23.5, and go won't add toolchain directive.

That will satisfy my ask to pin the toolchain at a specific version. In this case its implicitly specified by the go directive.

@trim21 I had observed that if renovate makes upgrades because of known CVEs in dependencies, it would ignore the go directive at all, and even upgrade. e.g. go1.22.0 to go1.22.13 and toolchain to go1.24.1 with this config:

  "vulnerabilityAlerts": {
    "enabled": true
  },

Might be unrelated to this PR, just giving a heads-up.

I don't know how go pick toolchain in this case...

[rarkins]

I think I'd be happy not to add the toolchain directive in the last case

[trim21]

I think I'd be happy not to add the toolchain directive in the last case

In that case we need to know which go version we will pick finally, it need go get ./... toolchain@none to do this, which only works on newer go version.

Need some kind of constraints on command I think, for example {cmd: '', constraints: {go: '>=1.21'}} to control if a command is executed based on the final version?

Another method is based on the go directive, if it's >1.21 then we add such argument, that's also possible, I think.

[trim21]

I think I'd be happy not to add the toolchain directive in the last case

In that case we need to know which go version we will pick finally, it need go get ./... toolchain@none to do this.

I think this is out of scope of this PR, this PR just want to resolve first 2 case.

It should be done with the removing of -d argument, they need same mechanism

[trim21]

👀 need anything else before merge?

[renovate-release]

🎉 This PR is included in version 39.200.1 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 39.200.1

Your semantic-release bot 📦🚀