Integration tests fails to run sql server on M1 chip

[sshquack]

The integration tests fail to run on macOS with M1 because Craftsman relies on mssql server image which has not yet been port to ARM64. The current workaround is to use azure sql edge. See this blog for details.

Steps to reproduce

• Scaffold any default example on macOS with M1 chip
• Try to run integration tests
• Notice that the tests hang-up because the mssql server docker image did not start

Further technical details

Craftsman version (dotnet tool list -g):

❯ dotnet tool list -g
Package Id      Version      Commands
--------------------------------------
craftsman       0.12.3       craftsman
dotnet-ef       6.0.1        dotnet-ef

Environment info

❯ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.101
 Commit:    ef49f6213a

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  12.1
 OS Platform: Darwin
 RID:         osx.12-arm64
 Base Path:   /usr/local/share/dotnet/sdk/6.0.101/

Host (useful for support):
  Version: 6.0.1
  Commit:  3a25a7f1cc

.NET SDKs installed:
  6.0.101 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Potential solutions

It took a few hours to figure this error. So we could do few things to help anyone else running into this issue:
Option 1: It might be worth to call this out in the getting started docs for folks with M1 chip
Option 2: Detect at Craftsman builder runtime (aka new:* commands) that the machine is a macOS with arm64 and generate azure-sql-edge
Option 3: At test runtime detect that the machine is a macOS with arm64 and use azure-sql-edge image. Can be found using the following:

> System.Runtime.InteropServices.RuntimeInformation.ProcessArchitecture
Arm64

> System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(OSPlatform.OSX)
true

Option 3 seems like a better solution since it would be clear in the code as why azure-sql-edge was chosen over ms-sql-server with some comments. I'd be happy to make a PR if your prefer option 3!

[pdevito3]

Oof this doesn't sound fun. Sorry for the headache here.

Do you know if MS has talked about a timeline for porting it to ARM64? Did you get yours working with ASE? Would be curious to see what it looks like and if there needs to be updates to areas other than the db utility (e.g. checkpoint and helper methods come to mind).

I do agree that option 3 would be best, but i am a little worried about the overhead it would add to the project.

At the very least, I can definitely update the docs and maybe even point to a gist with updates, but I could be open to option 3 to make it more portable. Could you send me what the end result might look like for the db util with option 3 and let me know if you had to update checkpoint, the helpers, or anything else I might be forgetting?

[sshquack]

@pdevito3 Don't be sorry at all. This is a small price to pay to advance processor architectures 😅

Regarding MS timeline, the SQL Server 2022 was launched in December and it is currently in closed preview. They provide no mention of if it will support ARM64 in their docs. I can only speculate what they will do. Even if they support ARM64, it would take them at least 6-8 months before they GA and publish the docker image.

Regarding SQL Edge, it basically runs on the exact same DB engine as SQL Server 2019 with support for ARM64. There are some unsupported features as documented here I used the SQL Edge and all the tests are passing and I'm able to connect to it using the same old SQL server DB drivers. So it should suffice for anyone trying this out on a macOS with M1.

My current thinking is to create a simple extension method to detect if the current machine is macOS + arm64 -> if yes, returns SQL edge image, else it returns SQL server 2019 image. I'll add comments as to why this is required so anyone reading the code can reference this issue quickly. Hopefully be end of year SQL server 2022 stable docker images gets published and we can remove this workaround. Let me know if that plan sounds reasonable to you. Expect a PR shortly!