ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 1 additional dependency was updated

Details:

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: renovate[bot]
Once this PR has been reviewed and has the lgtm label, please assign edsantiago for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Ephemeral COPR build failed. @containers/packit-build please check.

A friendly reminder that this PR had no activity for 30 days.

New changes are detected. LGTM label has been removed.

@Luap99 FYI As expected, Renovate is now unhappy with the hard-coded 1.21 in https://github.com/containers/automation/blob/4739c8921cc52a1c046c2d5248d88e6f8b8755de/renovate/defaults.json5#L126 .

Do we manually update every project before switching that?

@Luap99 FYI As expected, Renovate is now unhappy with the hard-coded 1.21 in https://github.com/containers/automation/blob/4739c8921cc52a1c046c2d5248d88e6f8b8755de/renovate/defaults.json5#L126 .

Do we manually update every project before switching that?

If we update the version there then renovate starts proposing go 1.22 upgrades to projects on 1.21 with a toolchain version we do not want right? And these likely pass CI and someone might merge them because of that without knowing that we dislike toolchain. But then without it all the projects on 1.22 are broken so I guess we should just switch it there

I do wonder though if we can set the "constraints": {"go": "1.21"}, in the per project config file instead, then we do not have to update all at once.

@Luap99 FYI As expected, Renovate is now unhappy with the hard-coded 1.21 in https://github.com/containers/automation/blob/4739c8921cc52a1c046c2d5248d88e6f8b8755de/renovate/defaults.json5#L126 .
Do we manually update every project before switching that?

If we update the version there then renovate starts proposing go 1.22 upgrades to projects on 1.21 with a toolchain version we do not want right?

Do you mean that we want Go 1.22 on Podman but not on some of the other projects? (If so, we probably need to move the constraint from the shared file.) Or that we do want Go 1.22 everywhere, but if we let Renovate do it, it will use a high version in the toolchain directive? (If so, we can update to Go 1.22 in all projects manually, and then update the Renovate config.)

I do wonder though if we can set the "constraints": {"go": "1.21"}, in the per project config file instead, then we do not have to update all at once.

That’s almost certainly possible; this file is included in the various projects’ .github/renovate.json5.

without knowing that we dislike toolchain.

(BTW I now see projects requiring specific X.Y.Z. versions of go, e.g. go 1.22.5 in one dependency of c/image. That might be harder to avoid than the toolchain dependency.)

but if we let Renovate do it, it will use a high version in the toolchain directive?

this

we can update to Go 1.22 in all projects manually

Right that is needed for the most projects anyway to fix CI configs to not run on f39 on cirrus and packit which makes this a PITA

Here are the other updates I did, I am not planning to work on the other repos migration bu happy to review
containers/common#2148
containers/buildah#5715

If so, we can update to Go 1.22 in all projects manually, and then update the Renovate config

Right but until this is done the renovate PRs in the projects with go 1.22 will fail, so depending on how long the process takes this may not be wanted.
I think having this in the per project config is better as we can switch it together with the go.mod bump and not have to deal with broken renovate PRs

For the record, the other updates:
containers/skopeo#2417
containers/image#2550

I mostly tend to prefer having these settings shared and managed centrally; I think we can get the updates done in a small number of days — it’s very easy to ignore Renovate PRs for a few days, but creating those PRs to move the configuration is immediate work and an ongoing commitment.

(BTW I now see projects requiring specific X.Y.Z. versions of go, e.g. go 1.22.5 in one dependency of c/image. That might be harder to avoid than the toolchain dependency.)

Do you know if this is intentionally on their end? This will suck big time.... What is even the point of forcing all consumers on a specific minor version? Just to ensure they build with specific go std bug fixes?? This will make tracking the versions really a pain, it is not just like were are dealing with fedora/debian upstream. Centos stream, epel/RHEL builds and so on. Other packagers that try to build podman, etc... we really cannot move the version requirements to fast.

I mostly tend to prefer having these settings shared and managed centrally; I think we can get the updates done in a small number of days — it’s very easy to ignore Renovate PRs for a few days, but creating those PRs to move the configuration is immediate work and an ongoing commitment.

Yes fair enough, as long as it takes a few days only I can live with the shared config.

(BTW I now see projects requiring specific X.Y.Z. versions of go, e.g. go 1.22.5 in one dependency of c/image. That might be harder to avoid than the toolchain dependency.)

Do you know if this is intentionally on their end?

In this case it’s things like sigstore/sigstore#1786 .

What is even the point of forcing all consumers on a specific minor version? Just to ensure they build with specific go std bug fixes?

The design intends to allow that, yes — and that notably includes security fixes. 1.22.5 does advertise security fixes.

This will make tracking the versions really a pain, it is not just like were are dealing with fedora/debian upstream. Centos stream, epel/RHEL builds and so on. Other packagers that try to build podman, etc... we really cannot move the version requirements to fast.

It seems to me that the primary restriction is on the 1.Y streams; within these streams, at least Fedora tends to update to 1.Y.X updates for security fixes rather than backport. I don’t know what Debian does.