image: use golang builder 1.24

[synarete]

Update to latest (from Feb 2025) golang version.

[anoopcs9]

Let's take this opportunity to match this version bump by updating the setup-go GitHub action in our workflow yaml to v5. To keep us updated with the minimum version supported please use the oldstable alias as described in the docs.

[synarete]

Let's take this opportunity to match this version bump by updating the setup-go GitHub action in our workflow yaml to v5. To keep us updated with the minimum version supported please use the oldstable alias as described in the docs.

Good point! will add another commit within this PR

[xhernandez]

Let's take this opportunity to match this version bump by updating the setup-go GitHub action in our workflow yaml to v5. To keep us updated with the minimum version supported please use the oldstable alias as described in the docs.

Using stable or oldstable will automatically switch versions when a new one is released. Couldn't this make identification of failures harder if the cause of the failure is some change introduced in the latest version ? on the other side, if we use a fixed version we'll always need to update it manually. I'm not sure what's better.

[synarete]

Let's take this opportunity to match this version bump by updating the setup-go GitHub action in our workflow yaml to v5. To keep us updated with the minimum version supported please use the oldstable alias as described in the docs.

Using stable or oldstable will automatically switch versions when a new one is released. Couldn't this make identification of failures harder if the cause of the failure is some change introduced in the latest version ? on the other side, if we use a fixed version we'll always need to update it manually. I'm not sure what's better.

We want to align with the common conventions of the Golang community. Unfortunately, it looks like an ever-moving target and will probably require some extra attention. As an example, I just realized that we would also need to upgrade some of the tooling we use, and therefore this PR is in-complete. I will close it and open a new one with all proper changes.

[synarete]

Need to do few more upgrades (tools) so will issue a new PR.

[anoopcs9]

Let's take this opportunity to match this version bump by updating the setup-go GitHub action in our workflow yaml to v5. To keep us updated with the minimum version supported please use the oldstable alias as described in the docs.

Using stable or oldstable will automatically switch versions when a new one is released. Couldn't this make identification of failures harder if the cause of the failure is some change introduced in the latest version ? on the other side, if we use a fixed version we'll always need to update it manually. I'm not sure what's better.

We want to align with the common conventions of the Golang community. Unfortunately, it looks like an ever-moving target and will probably require some extra attention. As an example, I just realized that we would also need to upgrade some of the tooling we use, and therefore this PR is in-complete. I will close it and open a new one with all proper changes.

I agree with @synarete. We have to deal with it using proper upgraded tool set as part of our CI runs.