pact-net
pact-net copied to clipboard
pact-foundation
feat(arm64): add arm64 osx libs
Do you really feel that it should wait for some undefined point in time when Github may add m1 support to actions? Considering there are no concrete timelines other than "we are working on it" I would much prefer this being merged as is, maybe with a comment in readme saying that m1 libs are not tested directly. Only case where this could fail is if somehow m1 lib that gets shipped starts behaving differently than non-m1 libs.
We've had other instances unfortunately where the core libs behave differently across different OSs, and one case where the Linux lib just completely crashed with no output or anything. That's why we set up the CI to run the tests on all platforms that we support.
I wouldn't want to ship to an arch that we aren't testing because our users (rightly) would assume that we've tested it to confirm it works. I don't personally have an M1 machine, so if a user did report a bug all I'd be able to say is "sorry, there's nothing I can do", which isn't great support for them.
I know what you're saying, like as a user it's better to have something rather than nothing, but as a maintainer I can't really ship code that I've not tested and can't support. As soon as M1 support is available in GHA and the CI passes there though, I'm very happy to ship M1 support.
Could we add a custom hosted runner? We could run it on the Pactflow AWS and foot the bill (or use the open collective funds). . FWIW we support M1 for JS but it is beta. We test the releases manually, so it's not ideal.
On Thu, 10 Feb 2022, 7:12 pm Adam Rodger, @.***> wrote:
We've had other instances unfortunately where the core libs behave differently across different OSs, and one case where the Linux lib just completely crashed with no output or anything. That's why we set up the CI to run the tests on all platforms that we support.
I wouldn't want to ship to an arch that we aren't testing because our users (rightly) would assume that we've tested it to confirm it works. I don't personally have an M1 machine, so if a user did report a bug all I'd be able to say is "sorry, there's nothing I can do", which isn't great support for them.
I know what you're saying, like as a user it's better to have something rather than nothing, but as a maintainer I can't really ship code that I've not tested and can't support. As soon as M1 support is available in GHA and the CI passes there though, I'm very happy to ship M1 support.
— Reply to this email directly, view it on GitHub https://github.com/pact-foundation/pact-net/pull/365#issuecomment-1034611554, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAANFDF2SKOGMZRGV5YAQ2LU2NXPTANCNFSM5N7ZACVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hi,
Is there any movement on this? We're looking at some proof of concept implementations, but a lot of our devs are on M1's and being unable to execute locally would definitely be a blocker.
I've put a request to our AWS account for M1 access and it has yet to be actioned. Any ideas on how we can reliably test on M1 would be welcome (ideally, when https://github.com/actions/virtual-environments/issues/2187 is available).
@mefellows thanks, appreciate an actual Github action would be the ideal scenario.
For anyone else who gets here from the docs, at least in my case Rosetta seems to work, it's not ideal but better than having to only test via CI, a cloud VM, or a colleague.
This sequence should get you a working build
$ arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
$ arch -x86_64 /usr/local/Homebrew/bin/brew install dotnet
$ arch -x86_64 /usr/local/opt/dotnet/bin/dotnet test
It shouldn't interfere with your existing M1 brew cause it conveniently installs itself under /opt on M1, so they stay separate.
Hi, any progress on this? Almost everyone in our org uses an M1 mac, and it would be nice to be able to run the verification locally without rosetta
M1 is now supported as a runner: https://github.blog/changelog/2022-08-09-github-actions-self-hosted-runners-now-support-apple-m1-hardware/ but we'd need to provide a self-hosted runner.
AWS now has M1 as GA and SmartBear would be happy to pay for these until GH actions makes them generally available on their own runners. If somebody is willing to do that work, we'd happily take ownership once it's working.
I know what you're saying, like as a user it's better to have something rather than nothing, but as a maintainer I can't really ship code that I've not tested and can't support. As soon as M1 support is available in GHA and the CI passes there though, I'm very happy to ship M1 support.
On this point, could we perhaps say that M1 support is experimental/untested for Pact .NET until such time as we have a repeatable process? I appreciate that one concern would be managing issues that get raised, and we could make the policy clear that we won't spend time debugging them until we have a CI environment?
If it helps, because I run M1 and use it daily, I can vouch for its support on NodeJS and Golang runtimes.
For anyone else landing here with the same issue, if you use Rider, there's a very easy workaround to make it work. Simply change de .NET CLI executable for the x64 as in this screenshot.
Enjoy!
Merging this in order to include arm64 support in the next release as a beta, although it won't be officially supported until we can run CI against it due to cross-platform issues we've had in the past which were only spotted during CI (since I can't run OSX builds locally given I don't own a Mac).