Upgrade various github actions.

[benjyw]

In particular, @v3 of upload-artifact and download-artifact
will soon fail. And @v3 of checkout relies on a deprecated
version of node.

[benjyw]

Note: A direct merge into 2.22.x to forestall any future CI issues on that branch. Not a cherrypick because the main branch versions of these upgrades are tangled with other changes. And this isn't a code change to Pants itself, so it's fine to merge directly.

[benjyw]

I also note that this may be naive, and @cburroughs has context that may require abandoning this. Although in that case we must do something else to avoid CI failures in a few weeks, when download/upload-artifact@v3 stops working entirely.

[huonw]

Thanks.

Auto-cherry-picker test failures are a bit weird/suspicious, maybe not spurious?

[benjyw]

Thanks.

Auto-cherry-picker test failures are a bit weird/suspicious, maybe not spurious?

Yeah, unlikely to be unrelated... But first I want to hear from @cburroughs on whether this even makes sense,

[cburroughs]

I've been trying to page all this context back in. So the question is how to support older release branches without #21650 ?

NOTE: I think we should bump the manylinux version in main regardless, but if my read if the situation is correct we may need to backport this any active release line. Without this or a more complex change we would also be unable to release after December 5th per #21616.

Yeah, I was not an am not sure what to do. It's awkward to change the minimum glibc version mid release but as described in the original PR I don't think it is actually going to have an effect on anyone in practice.

• (A) update the manylinux wheel glibc version to 2.28 #21650 is a largish change to backport to 2.22 as this PR describes, but maybe would still fit on 2.24?
• (B) Just update the Action versions as this PR does. If that works, great! But I don't think that works because then we end up running with the New Node on the too-old manylinux containers? We don't actually test building the wheels on each PR, which I tired to fix in update the manylinux wheel glibc version to 2.28 #21650 but per Prepare 2.25.0.dev1 #21733 that was maybe not successfully.
• (C) Update the action versions and the manylinux version? I think this would work, just an annoying amount of divergence across branches (and the minor glibc bump).
• (D) Retire (some of) these release lines "early". 2.22.x just has Use the major version of golang at package time (Cherry-pick of #21523) #21617 as the only non-CI change for example.

[benjyw]

Hmm, yeah, I suspect D) may be what we have to do, after getting one more stable release from that branch.

But I notice that #21650 is on 2.23.x but not 2.24.x. How did that happen? Is that by design?

[cburroughs]

But I notice that #21650 is on 2.23.x but not 2.24.x. How did that happen? Is that by design?

mm, I thought you were the one who did the backporting to 2.23.x ;-) #21660 But I'm not sure why WorkerPants wasn't able to do it.

[cburroughs]

Taking a stab for 2.24.x at #21754

[huonw]

I'm trying to prep a 2.22.2 rc in #21769 and observed failures that this would fix. So, I don't think we can do one more stable release from 2.22.x without some sort of resolution here.

There's been no major change to the 2.22.x branch since the earlier discussions (#21617 is still the only real change since 2.22.1). So it feels fine to just let it go: close 2.22.x now with 2.22.1 as the last release.

Thoughts?

[benjyw]

Fine with me. GHA is kind of forcing our hand here.

[cburroughs]

So it feels fine to just let it go: close 2.22.x now with 2.22.1 as the last release.

👍

[benjyw]

So I should close this, presumably.