CoreCLR runtime tests + Mono on the x64 iOS simulator (#43954)
authorimhameed <imhameed@microsoft.com>
Tue, 3 Aug 2021 22:49:26 +0000 (18:49 -0400)
committerGitHub <noreply@github.com>
Tue, 3 Aug 2021 22:49:26 +0000 (15:49 -0700)
commitda803ac809dcf03c689079b2f707f5a4e1e15653
treeed3909ad5283d1f56aecd0e98c4858728e73acd3
parenta35aff789d148cd7549cad9040026d05e160021d
CoreCLR runtime tests + Mono on the x64 iOS simulator (#43954)

This creates another `runtime-staging` lane, named "Build iOSSimulator x64
Release AllSubsets_Mono_RuntimeTests", that will eventually run the runtime
test suite against Mono's non-LLVM JIT on the iOS simulator on amd64 hosts.
Failing tests are added to the exclusion lists in issues.targets.

The tests aren't set to run yet, because they currently take a very long time
to execute.

`AppleAppBuilder` no longer requires a `MainLibraryFileName`. If omitted, one
must be supplied when the app bundle is launched via an environment variable
named `MONO_APPLE_APP_ENTRY_POINT_LIB_NAME`. The generated apps also accept
another environment variable named `MONO_APPLE_APP_ASSEMBLY_LOAD_PREFIX`, which
is a hack used to allow assembly lookup to proceed in a nested app-relative
subdirectory before falling back to the root of the app bundle. This is
necessary because app bundles contain multiple individual test assemblies, and
these assemblies sometimes have dependencies with names that collide with the
dependencies of other test assemblies inside the bundle.
13 files changed:
eng/pipelines/coreclr/templates/helix-queues-setup.yml
eng/pipelines/runtime-staging.yml
src/tasks/AppleAppBuilder/AppleAppBuilder.cs
src/tasks/AppleAppBuilder/Templates/runtime.m
src/tests/Common/CLRTest.Execute.Bash.targets
src/tests/Common/Coreclr.TestWrapper/MobileAppHandler.cs
src/tests/Common/helixpublishwitharcade.proj
src/tests/Common/tests.targets
src/tests/Directory.Build.targets
src/tests/Interop/ICastable/Castable.csproj
src/tests/build.sh
src/tests/issues.targets
src/tests/run.proj