Don't load SentryNative on unsupported platforms

[jamescrosswell]

@devtekve Thanks a lot for the test case, very helpful! 👍 I should've guessed from "Mac" being mentioned that this was ARM64. 🙂 sentry-dotnet currently has native support for linux-x64, linux-arm64, and linux-musl-x64. The target you use i.e. linux-musl-arm64 is missing, unfortunately. While sentry-dotnet should be fixed not to try to load the native library on an unsupported platform, you probably don't even need native for your deployment, maybe you could set -p:SentryNative=false to get past the loading issue? Feel free to open a request to add native support on linux-musl-arm64 if it's relevant for your use case.

Originally posted by @jpnurmi in #4296

[jpnurmi]

Testing anything but x86_64 with Alpine containers might be painful in GitHub Actions because even basic things such as actions/checkout doesn't work... 🙁

For some reason, actions/runner has a hard-coded architecture check for JS actions, so it doesn't even matter if we prepare the image with nodejs and npm pre-installed:

            if (!Constants.Runner.PlatformArchitecture.Equals(Constants.Architecture.X64))
            {
                var os = Constants.Runner.Platform.ToString();
                var arch = Constants.Runner.PlatformArchitecture.ToString();
                var msg = $"JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected {os} {arch}";
                throw new NotSupportedException(msg);
            }

https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/StepHost.cs#L268-L274

[jpnurmi]

• GitHub Actions container runners use pre-built Node from /__e/node20 bind-mounted from the host.

  The runner carries its own copy of node.js executable under <runner_root>/externals/node20/.

  All javascript base Actions will get executed by the built-in node at <runner_root>/externals/node20/.

  Not the node from $PATH

  https://github.com/actions/runner/blob/main/docs/checks/nodejs.md

• There's a potential workaround to override the /__e/node20 mount and that way provide your own /__e/node20/bin/node that can be linked straight to the system installation.

  • [bug] v2, v3 and v4 fail in 32-bit containers actions/upload-artifact#616 (comment)

[devtekve]

• GitHub Actions container runners use pre-built Node from /__e/node20 bind-mounted from the host.

  The runner carries its own copy of node.js executable under <runner_root>/externals/node20/.

  All javascript base Actions will get executed by the built-in node at <runner_root>/externals/node20/.

  Not the node from $PATH

  https://github.com/actions/runner/blob/main/docs/checks/nodejs.md

• There's a potential workaround to override the /__e/node20 mount and that way provide your own /__e/node20/bin/node that can be linked straight to the system installation.

  • [bug] v2, v3 and v4 fail in 32-bit containers actions/upload-artifact#616 (comment)

Sorry for the ignorance but why do you need to run the action itself on alpine? You can run it on Ubuntu and use docker, or am I missing something here?

[jpnurmi]

One could add a separate job and run a few Docker commands to reproduce the issue the same way we do locally, but I wanted to integrate it with the existing matrix to be able to collect build artifacts and run it through the same test suite as all other platforms. It will not only reproduce the issue but also paves the road for adding platform support for linux-musl-arm64. 🙂