Switch from bitness to architecture
#590
Conversation
dennisameling
force-pushed
the
bitness-to-architecture
branch
from
4db55d9 to
9a114ae
Compare
As we're moving away from bitness in favor of architecture, let's update the logic in setup-git-for-windows-sdk as well. This also adds support for aarch64 in create-sdk-artifact, which we couldn't do with bitness. Signed-off-by: Dennis Ameling <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Dennis Ameling <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
bitness-to-architecture
branch
from
9a114ae to
1a6b81c
Compare
|
@dennisameling do we need anything else to support |
|
Theoretically speaking, everything should work now. Let's test! |
|
Doh. Completely overlooked the block we had in place for all "non-full" flavors of the arm64 SDK. Let's get rid of that. |
It's working now! 🚀 The So it looks like the new version of the Action is ready to be published at least! 😊 |
Darn. https://github.com/git-for-windows/git-for-windows-automation/actions/runs/4108411699/jobs/7089072793#step:10:482 means that The problem is that incomplete @dennisameling I see you already sync'ed, so you're aware of the problem 😁 |
|
I'm signing off for today but have a feeling that the pipeline will work just fine when we retry it now that the |
|
@dennisameling yep, let's get a good night's sleep before celebrating a working build (I have no doubt that it'll work) ;-) |
|
Ok, I had to tweak a few other minor things, and the build of The "Test-deploy Pacman packages" part is failing now and I'm not sure whether that's related to the |
That could be the code-signing. It has to contact a server for the validated timestamp and that sometimes causes hiccups (but I do not recall seeing any of these issues in the past few years). 🎉🎉🎉🎉🎉
Hmm. It says that the |
I am fairly certain that this failure happens in this line. I remember that the However, that could have changed in the meantime. After all, clicketyclick msys2/MSYS2-packages@e7424d8 does not seem as if it could be responsible for this. Let me try a local dry-run and come back to you. |
|
I cannot reproduce locally, but I have a hunch that maybe these lines are responsible... |
|
Let's see whether I can debug interactively with tmate. |
|
You might as well just run the |
No, I already tried as manual testing as possible, but cannot replicate the issue. So it's probably something to do with the Actions environment. Maybe symbolic links are enabled or something. |
|
Okay, my give up. I'll start my Windows/ARM64 VM and hope that I can reproduce there... |
|
As I feared, I cannot reproduce in my VM. |
|
Aha! I just noticed this line. That's the "Maybe symbolic links are enabled" thing: |
|
Good catch! That's clearly coming from |
|
Whoa! But it's not even in |
|
Looks like that was introduced in |
I don't want to wait that long, and I don't want to be stuck with an eternally-obsolete dependency. So I opened git-for-windows/build-extra#477. |
|
Let's try again! 🤞🏼 |
|
It hang again, so I had to restart. This time it worked! 🎉🎉🎉🎉🎉🎉🎉 Here's a PR to incorporate my temporary fixes into the |
I think we're good to release v1.8.0 now, right? 😊 |
Yes!!! |
Needs git-for-windows/build-extra#462 to be merged first
As we're moving away from
bitnessin favor ofarchitecture, let's update the logic insetup-git-for-windows-sdkas well. This also adds support foraarch64increate-sdk-artifact, which we couldn't do withbitness.