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

[rarkins]

Does this definitely work if we are upgrading the tool chain version?

[trim21]

Does this definitely work if we are upgrading the tool chain version?

I don't know, that's what I'm asking since #34564 (comment)

If you also don't know it for sure, I'd suggest we go back again using getGoConstraints(massagedGoMod) , which definitely works.

[casaqori]

Interested in this feature.
Would that change then allow toolchain pinning?
For motivation see reply on #34563

[trim21]

Interested in this feature. Would that change then allow toolchain pinning? For motivation see reply on #34563

In my understanding after this change only updateType=toolchain will change toolchain directive, package only change will not change it anymore

[trim21]

There is acually a corner case, when a go.mod has go major.minor.path without toolchain directive for example go 1.23.5, renovate still pick latest go version and add a toolchain directive. but go itself will pick 1.23.5, in my understanding.

[trim21]

After this PR, based on go.mod novatebot will behave like this:

For go.mod:

go 1.22
toolchain go1.23.5

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

For go.mod:

go 1.23.5

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

This PR currently fix these 2 cases.

---

And a remaining case is this:

For go.mod, without toolchain directive

go 1.23

renovate now pick latest version of go 1 (go1.24.1 at the time of writing), and go will add toolchain directive toolchain go1.24.1

And to make go to not add toolchain directive, we will need to run go get with go get ./... toolchain@none, which maybe a breaking change for some users.

[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...

[viceice]

drop it and add a should not be called expect after update artifacts

Suggested change

	datasource.getPkgReleases.mockResolvedValueOnce({
	releases: [
	{ version: '1.17.0' },
	{ version: '1.23.6' },
	{ version: '1.24.0' },
	],
	});

[viceice]

same here