CI - Run unity tests through cargo test

[bfops]

Description of Changes

The unity testsuite can now be run via cargo test using a Rust crate. This has also been threaded into cargo ci.

We also updated the unity tests to accept an arbitrary server url instead of hardcoding one, so we can use the existing SpacetimeDBGuard.

API and ABI breaking changes

Expected complexity level and risk

2

Testing

• Tests pass, and it lists which tests passed

[jdetter]

This looks great so far, just one question from me.

I think it's a bit bad dev UX that a unity path is required:

could not find Unity. Pass --unity-path, set UNITY_PATH or UNITY_EXECUTABLE, install Unity 2022.3.32f1 in a standard GitHub runner path, or set UNITY_USE_DOCKER=1
error: test failed, to rerun pass `-p spacetimedb-unity-tests --test unity`

Caused by:
  process didn't exit successfully: `C:\Users\boppy\clockwork\SpacetimeDB\target\debug\deps\unity-5022c0874751acf7.exe` (exit code: 1)
Error: command ["cargo", "test", "-p", "spacetimedb-unity-tests", "--test", "unity"] exited with code 1
error: process didn't exit successfully: `target\debug\ci.exe unity-tests --skip-dlls` (exit code: 1)

I think the error message here is helpful enough here where it wouldn't take a typical developer long to get the right parameter so I think it's fine. I think a better dev UX would be that if you could specify a unity version then we could try to find that unity version at the typical install paths and then if we can't find it we just give up. We definitely shouldn't just use whatever Unity version is available, I think you should at least have to specify that. What do you think?

[jdetter]

Did we not need this? I can't seem to find these changes in the unity.rs file

[jdetter]

We at least need to dotnet pack and move the binaries into the proper place within the Unity repo, no?

[jdetter]

One more thing on this, I actually tried to pass --unity-path and it didn't work:

PS C:\Users\boppy\clockwork\SpacetimeDB> cargo ci unity-tests --skip-dlls --unity-path 'C:\Program Files\Unity\Hub\Editor\2022.3.62f3\Editor'
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.46s
     Running `target\debug\ci.exe unity-tests --skip-dlls --unity-path "C:\Program Files\Unity\Hub\Editor\2022.3.62f3\Editor"`
error: unexpected argument '--unity-path' found

Usage: ci.exe unity-tests --skip-dlls

For more information, try '--help'.
error: process didn't exit successfully: `target\debug\ci.exe unity-tests --skip-dlls --unity-path "C:\Program Files\Unity\Hub\Editor\2022.3.62f3\Editor"` (exit code: 2)

[jdetter]

The C# tests didn't work immediately for me in WSL so I asked Codex to try to fix it and it came up with these 2 changes that it thought we should make:

  1. crates/csharp-tests/tests/csharp.rs

  The test harness was packing C# packages into their normal project output dirs:

  crates/bindings-csharp/*/bin/Release

  Those dirs already contained stale packages, including old 1.11.2 packages. Then the generated NuGet.Config pointed NuGet at those dirty dirs, so restore could resolve
  old local packages instead of the packages just built by the test.

  I changed the harness to:

  - delete/recreate target/csharp-tests/local-feed
  - pack SpacetimeDB.BSATN.Runtime and SpacetimeDB.Runtime into that clean feed
  - write NuGet.Config to consume SpacetimeDB packages from that feed
  - use -p:BuildInParallel=false / --disable-parallel for more reliable MSBuild invocation

  Why needed: the test should be hermetic with respect to local package output. It should test packages built from the current checkout, not whatever old .nupkg happens to
  be lying around.

  2. sdks/csharp/examples~/regression-tests/republishing/*/StdbModule.csproj

  Both republishing module fixtures were pinned to:

  <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.0" />

  But their C# source uses newer runtime/codegen surface, for example table Accessor and [Default(...)]. Those symbols are not available in 1.5.0, so once the stale local
  package behavior was removed, the fixture failed honestly with missing-symbol errors.

  I changed both to:

  <PackageReference Include="SpacetimeDB.Runtime" Version="2.2.*" />

  Why needed: these fixtures are part of the current SDK regression suite and need to compile against the current runtime API. The test is about republishing/migration
  behavior, not compatibility with a 1.5.0 C# runtime.

I'm not sure how important it is, but we probably should be bumping these versions in the upgrade version script:

diff --git a/sdks/csharp/examples~/regression-tests/republishing/server-initial/StdbModule.csproj b/sdks/csharp/examples~/regression-tests/republishing/server-initial/StdbModule.csproj
index 3d6a76999..6fe4266c4 100644
--- a/sdks/csharp/examples~/regression-tests/republishing/server-initial/StdbModule.csproj
+++ b/sdks/csharp/examples~/regression-tests/republishing/server-initial/StdbModule.csproj
@@ -8,7 +8,7 @@
   </PropertyGroup>

   <ItemGroup>
-    <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.0" />
+    <PackageReference Include="SpacetimeDB.Runtime" Version="2.2.*" />
   </ItemGroup>

 </Project>
diff --git a/sdks/csharp/examples~/regression-tests/republishing/server-republish/StdbModule.csproj b/sdks/csharp/examples~/regression-tests/republishing/server-republish/StdbModule.csproj
index 3d6a76999..6fe4266c4 100644
--- a/sdks/csharp/examples~/regression-tests/republishing/server-republish/StdbModule.csproj
+++ b/sdks/csharp/examples~/regression-tests/republishing/server-republish/StdbModule.csproj
@@ -8,7 +8,7 @@
   </PropertyGroup>

   <ItemGroup>
-    <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.0" />
+    <PackageReference Include="SpacetimeDB.Runtime" Version="2.2.*" />
   </ItemGroup>

 </Project