go-winio may need a fix for go1.22; see

• update to go1.22.6 moby/moby#46982
• fileinfo: internally fix FileBasicInfo memory alignment microsoft/go-winio#312

We're preparing 2.0 release and I think we should use go1.21 because it's stable. Go1.22 should be applied after 2.0 release if there is no required feature using go1.22.

@fuweid @kiashok we had discussed this earlier, staying on 1.21 for the 2.0 release but replacing building 1.20 with 1.22 in the build matrix. Agreed we should not move up a go release yet, but we can remove 1.20 support and make sure we are building against 1.22. This is typically the state release branches end up anyway, test and release with n-1 go version but ensure builds with latest.

@fuweid @kiashok we had discussed this earlier, staying on 1.21 for the 2.0 release but replacing building 1.20 with 1.22 in the build matrix. Agreed we should not move up a go release yet, but we can remove 1.20 support and make sure we are building against 1.22. This is typically the state release branches end up anyway, test and release with n-1 go version but ensure builds with latest.

Oh okay sorry, I think I misunderstood it. Will work on this right now and push new changes

Apparently Go 1.22 has a regression (affects runc)

• runtime: SIGSEGV after performing clone(CLONE_PARENT) via C constructor prior to runtime start golang/go#65625

We saw other issues with CGO as well (broken on some 32-bit arm versions)

LGTM on green

tests are passing now @fuweid @dmcgowan @mikebrow

We saw other issues with CGO as well (broken on some 32-bit arm versions)

This isn't a blocker for this PR since we are only doing a build check against 1.22 and not switching the test/release pipelines before 2.0.