Use publicly available Apple Silicon runners#9726
Conversation
2740770 to
fda48e1
Compare
| run: | | ||
| pip install dist/${{ env.PACKAGE_NAME }}-*.whl --force-reinstall | ||
| ruff --help | ||
| python -m ruff --help |
There was a problem hiding this comment.
Unfortunately we can no longer run the x64_64 wheel (since this is an ARM runner, we're cross-compiling), but I think it's fine and worth it (we already run this test in the Universal branch below).
There was a problem hiding this comment.
IMO if the M1 runner has Rostta2 enabled it should run fine? At least for ruff --help.
There was a problem hiding this comment.
Lemme look back at what failed...
There was a problem hiding this comment.
I think it was the pip install dist/${{ env.PACKAGE_NAME }}-*.whl --force-reinstall, saying that the wheel isn't supported for the current platform.
There was a problem hiding this comment.
Oh right, the python interpreter it installed might not be universal2, if it is you can probably use arch -x86_64 python to switch to x86_64 mode.
Anyway it's definitly not a big issue.
There was a problem hiding this comment.
I appreciate you chiming in, you're always so helpful.
This reverts commit f0066e1.
## Summary Sadly, the Apple Silicon runners use macOS 14 and produce binaries that segfault when run on macOS 11 (at least), and possibly on macOS 12 and/or macOS 13. macOS 11 is EOL, but it doesn't seem like a good tradeoff to speed up our release builds at the expense of user support and compatibility. This reverts commit f0066e1. Closes #9823.
…sh#9726)" (astral-sh#9834)" This reverts commit 7390232.
Summary
This PR switches over to the
macos-14runners for our macOS wheel builds, which are GitHub's newly announced public M1 macOS runners (https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/).Before:
After:
So it's like > 3x speedup for what is currently the bottleneck in our release pipeline.