First of all, the GitHub team is committed to bringing the Windows 11 ARM image under its ownership

This is great news. We will be much more interested in merging this and resuming win_arm64 support once this transition has occurred!

Just for reference as we track this: Our desired end state would be being able to treat the WoA builders exactly as we do x86_64 Windows. Bringing it back in-house and making sure there aren't basic image differences/broken core actions will be enormously helpful.

Thanks for working on this. Just to hone in on what Paul said, we really don't want to carry a big "if arm64" block :-) And ideally we wouldn't have to carry that much windows specific code (if PyManager is the right thing, maybe setup-python should use it?)

@alex Yeah, I don't like this big chunk neither. I've asked maintainer if we can have pymanager included in the image, that should trim down this fix a lot.

I have good news I can't share yet, but just want to let you know we are not abandoned this and working on full resolution.

@khmyznikov FYI, it looks like there's been another regression in win-arm64 + setup-python -- see pyca/bcrypt#1193. I haven't fully diagnosed the cause.

I do see that the image has moved from partner images to the primary image repo, which is an encouraging signal. But to be very direct: repeated breakages like this are precisely the concern we had that led to us not re-adding arm64 to our CI after the original issue was fixed.

@alex Thank you for keeping your finger on the pulse! As a first step, we expect the image to be moved to the main repository very soon. I’m discussing with the team how we can best publicly demonstrate the readiness of new versions. I would be happy to hear any suggestions regarding CI testing.

I don't know a ton about what y'all already do, so there's a big risk of suggesting things that y'all already do. That said, here are some things I suspect are not currently done:

• Smoke tests with live actions. When a new image is ready to be pushed, deploy it with some internal ubuntu-22.04-secret-next or whatever label, and then run some real jobs. You can build up a set of workflows that excersise common things: test every supported python version with setup-python on the new image, for example. If those all pass, then it can move on to next gates.
• This is harder, but some sort of shadow/canary builds: pick some real repos+workflows, and when they're triggered, add shadow versions of jobs using the new image and run them. If the new image fails and the old one passed, that's a potential indicator of problems.

Let me add that working rapidly to fix major breakage is also critical. I say this because the basic and total breakage of setup-python for a subset of versions on windows arm64, which we noted 2 days ago, is not fixed and we have no idea when it will be. That's so far beyond unacceptable as to border on farce. Since we've had our entire CI blocked in both PyNaCl and bcrypt due to this we'll be dropping Windows ARM support there today as well.

@reaperhulk please hold. GitHub team reproduces the issue and willing to address it ASAP. The issues was they didn't tested the latest package of the setup python, which was resolved and now will be included into test matrix.