Upgrade Porch to Go 1.22

[liamfallon]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind bug

/kind cleanup

/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:

• Updated go version in go.mod files
• Updated go version in github workflows
• Updated base image to 1.22.2-bookworm in Dockerfiles
• Updated Go/Golang-CI/GoSec versions in makefiles

Which issue(s) this PR fixes:
Fixes Issue 510.

Special notes for your reviewer:

Does this PR introduce a user-facing change?:
no

[nephio-prow]

@liamfallon: The label(s) kind/cleanup cannot be applied, because the repository doesn't have them.

In response to this:

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind bug

/kind cleanup

/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:

• Updated go version in go.mod files
• Updated go version in github workflows
• Updated base image to 1.22.2-bookworm in Dockerfiles
• Updated Go/Golang-CI/GoSec versions in makefiles

Which issue(s) this PR fixes:
Fixes Issue 510.

Special notes for your reviewer:

Does this PR introduce a user-facing change?:
no

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[liamfallon]

/assign @tliron @Catalin-Stratulat-Ericsson

[liamfallon]

/assign @vjayaramrh

[efiacor]

/approve

[liamfallon]

Replacing reflect.TypeOf() with reflect.TypeFor doesn't seem to be useful at the other four locations where reflect.TypeFor() occurs in the code base:

1. porch/func/evaluator/evaluator.pb.go

   Line 315 in 48bb15a

   GoPackagePath: reflect.TypeOf(x{}).PkgPath(),

   where reflect.TypeOf() is used as a mechanism to get the package oath

2. porch/pkg/git/git_test.go

   Line 62 in 48bb15a

   st := reflect.TypeOf(suite)

   where reflect.TypeOf() is used on an interface

3. porch/test/e2e/e2e_test.go

   Line 69 in 48bb15a

   st := reflect.TypeOf(suite)

   where reflect.TypeOf() is used on an interface

4. porch/api/generated/informers/externalversions/factory.go

   Line 182 in 48bb15a

   informerType := reflect.TypeOf(obj)

   where reflect.TypeOf() is in generated code

[liamfallon]

/recheck

[liamfallon]

/retest

[liamfallon]

The go tests need to be upgraded to Go 1.22, see nephio-project/test-infra#258
/hold

[liamfallon]

/retest

[efiacor]

/retest

Do we need to bump the gotest image in the .prow file to nephio/gotests:1782782171367346176 ?

https://github.com/nephio-project/porch/blob/main/.prow.yaml#L7

[liamfallon]

/retest

[liamfallon]

The toolchain has been updated for go 1.22 now, thanks to @radoslawc. This PR is ready for review.
/assign @tliron @efiacor @vjayaramrh

[efiacor]

/approve

[vjayaramrh]

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

[liamfallon]

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

Yes, this is a good idea. There are also toolchain changes to make in test-infra, which @radoslawc did. I think it would be best this time to go ahead with these PRs and then write a separate issue to look at and implement automation of the go version change. At least now with this PR and Rado's PRs we know where the changes that need to be automated are.

[efiacor]

/lgtm

[vjayaramrh]

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

Yes, this is a good idea. There are also toolchain changes to make in test-infra, which @radoslawc did. I think it would be best this time to go ahead with these PRs and then write a separate issue to look at and implement automation of the go version change. At least now with this PR and Rado's PRs we know where the changes that need to be automated are.

Sounds good, Do you mind adding the issue link here so that this does not get lost prior to merging this issue, Thanks

[efiacor]

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

Yes, this is a good idea. There are also toolchain changes to make in test-infra, which @radoslawc did. I think it would be best this time to go ahead with these PRs and then write a separate issue to look at and implement automation of the go version change. At least now with this PR and Rado's PRs we know where the changes that need to be automated are.

Sounds good, Do you mind adding the issue link here so that this does not get lost prior to merging this issue, Thanks

Hey @vjayaramrh , created this one - nephio-project/nephio#731
Not sure how to link it here though.

[vjayaramrh]

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

Yes, this is a good idea. There are also toolchain changes to make in test-infra, which @radoslawc did. I think it would be best this time to go ahead with these PRs and then write a separate issue to look at and implement automation of the go version change. At least now with this PR and Rado's PRs we know where the changes that need to be automated are.

Sounds good, Do you mind adding the issue link here so that this does not get lost prior to merging this issue, Thanks

Hey @vjayaramrh , created this one - nephio-project/nephio#731 Not sure how to link it here though.

Would it be a good idea to set a variable for the GO Version and then change the value for the version in one file? Looks like we would end up changing multiple files which may be error prone. Any thoughts?

Yes, this is a good idea. There are also toolchain changes to make in test-infra, which @radoslawc did. I think it would be best this time to go ahead with these PRs and then write a separate issue to look at and implement automation of the go version change. At least now with this PR and Rado's PRs we know where the changes that need to be automated are.

Sounds good, Do you mind adding the issue link here so that this does not get lost prior to merging this issue, Thanks

Hey @vjayaramrh , created this one - nephio-project/nephio#731 Not sure how to link it here though.

@efiacor Thanks, I think we are all set.

[efiacor]

/approve
/lgtm

[efiacor]

I think we will have to bump the image version here also
https://github.com/nephio-project/porch/pull/41/files#diff-e48abb6eaacd63e53dd63fec4562daff0b7766146c230ceaa515ee087367e1f8L28

[liamfallon]

/approve

[liamfallon]

I think we will have to bump the image version here also https://github.com/nephio-project/porch/pull/41/files#diff-e48abb6eaacd63e53dd63fec4562daff0b7766146c230ceaa515ee087367e1f8L28

@efiacor I'll raise a subsequent PR to add this if that's OK with you

[efiacor]

/approve
/lgtm

[radoslawc]

closing for testing tide fix

[liamfallon]

/approve

[nephio-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: efiacor, liamfallon

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [efiacor,liamfallon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[efiacor]

/lgtm