-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ios][tests] Run functional tests with Mono and Native AOT on Helix #87773
[ios][tests] Run functional tests with Mono and Native AOT on Helix #87773
Conversation
Tagging subscribers to this area: @directhex Issue DetailsWork in progress. This PR aims to add the Mono and Native AOT iOS samples as functional tests on a device to the Helix. Currently, it includes some temporary workarounds that will be resolved once the CI reports green. initial work can be found at https://github.com/steveisok/runtime/tree/ios-sample-lib-targets. DescriptionTBD
|
These are the artifacts we need to replace when
|
Update: When adding new artifacts to the Helix, update the |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the two nits, this looks good.
However, since it is a quite large PR I would suggest someone else also to take a look before merging.
src/tests/FunctionalTests/iOS/Simulator/AOT-LLVM/iOS.Simulator.Aot-Llvm.Test.csproj
Outdated
Show resolved
Hide resolved
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thanks for sticking with it.
<_AOTBuildCommand>$(_AOTBuildCommand) /p:XHARNESS_EXECUTION_DIR="$XHARNESS_EXECUTION_DIR" /p:RunAOTCompilation=$(RunAOTCompilation) /p:TargetOS=$(TargetOS) /p:TargetArchitecture=$(TargetArchitecture) /p:MonoForceInterpreter=$(MonoForceInterpreter) /p:MonoEnableLLVM=true /p:DevTeamProvisioning=$(DevTeamProvisioning) /p:UsePortableRuntimePack=true /p:Configuration=$(Configuration)</_AOTBuildCommand> | ||
<_AOTBuildCommand>$(_AOTBuildCommand) /p:XHARNESS_EXECUTION_DIR="$XHARNESS_EXECUTION_DIR" /p:RunAOTCompilation=$(RunAOTCompilation) /p:UseNativeAOTRuntime=$(UseNativeAOTRuntime) /p:TargetOS=$(TargetOS) /p:TargetArchitecture=$(TargetArchitecture) /p:MonoForceInterpreter=$(MonoForceInterpreter) /p:DevTeamProvisioning=$(DevTeamProvisioning) /p:UsePortableRuntimePack=true /p:Configuration=$(Configuration)</_AOTBuildCommand> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the other functional tests project files, most of them have
MonoForceInterpreter
set, but some haveTreatAsLocalProperty="MonoForceInterpreter"
some don't, so I believe theTreatAsLocalProperty
was added as a workaround to prevent overwriting what a project specifies through the command line - like building on Helix.To conclude, I feel like this needs to be refactored (maybe not in this PR), with either removing any notion of
MonoForceInterpreter
from the functional test's project file (and test the change), or leave it how it was to prevent any unwanted regression.@steveisok what do you think?
I would suggest keeping it and slowly unwinding in a follow up.
# iOS/tvOS devices | ||
# Build the whole product using Native AOT and run libraries tests | ||
# | ||
- template: /eng/pipelines/common/platform-matrix.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have the capacity to run these on every PR. Even when we kick off runtime-ioslike manually, there may be a capacity issue running both mono and nativeaot together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, my concern was all libraries tests (when we get to it) and I see it's running smoke tests only.
Hey, I just noticed this is running libraries tests using Native AOT in the |
This concern was already previously voiced in a comment. The conclusion was that it runs only small subset of the tests (smoke tests). Are you seeing a bigger subset now? If it becomes an issue, is it possible to trigger it on specific path changes automatically? |
Ah, nevermind, I see now this is only smoke tests. OK, lemme look in more detail at average run times. If it's not too expensive, we can continue running smoke tests. |
Description
Initial work can be found at https://github.com/steveisok/runtime/tree/ios-sample-lib-targets.
This PR adds support for Native AOT compilation on Helix. It improves test coverage for Mono and Native AOT by running functional tests on Helix. The proxy project is updated with Native AOT props and apple build targets are updated to support Native AOT compilation. Additionally, it simplifies the sample app by utilizing the shared Apple targets.
Fixes #85294