You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just noticed that aftman chose the wrong binary when installing one of our internal tools:
In the screenshot you can see that the files downloaded are definitely x86 while the architecture I'm using is arm.
If I delete the x86_64 binary from the release aftman correctly picks the aarch64 one.
I think we're relying on the Ord implementation of Architecture for this. The hope is that on systems that support AArch64 AND x86-64, we should pick AArch64. The opposite might be happening?
This is obviously not a great way solution as it makes this code very hard to debug.
At some point we should pull this code out so we can write better tests for it.
I think we're relying on the Ord implementation of Architecture for this. The hope is that on systems that support AArch64 AND x86-64, we should pick AArch64. The opposite might be happening?
Did some diagnosing of this issue and when running locally it actually picked up the correct artifacts, the issue seems to be a missing --target flag during the release build. Basically, std::env::consts::ARCH was set to x86_64 even for aarch64 builds since that's what github's hosted runner is using, and rosetta magic made aftman still work for macOS. I'll make a quick PR to fix it.
Just noticed that aftman chose the wrong binary when installing one of our internal tools:
In the screenshot you can see that the files downloaded are definitely x86 while the architecture I'm using is arm.
If I delete the
x86_64
binary from the release aftman correctly picks theaarch64
one.I'm thinking something might be going wrong during artifact selection / ordering
The text was updated successfully, but these errors were encountered: