-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Add test leg to the PR build to run libraries tests on iOS x64 Simulators #37476
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
Conversation
Tagging subscribers to this area: @ViktorHofer |
Commenter does not have sufficient privileges for PR 37476 in repo dotnet/runtime |
71b4ee2
to
be7b233
Compare
…to prvysoky/use-helix-sdk
None of these fixes are wrong per se (maybe the ApkBuilder changes?) but they complicate the PR by mixing unrelated changes
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.
LGTM!
|
||
dotnet xharness ios test --app="$APP_BUNDLE" \ | ||
--targets=$TARGET \ | ||
dotnet xharness ios test \ |
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.
Will we support filtering tests or any xunit parameters? Like -notrait Category=Outerloop
? If so, this is wrong and should use RunScriptCommand
in the MSBuild side to set this command.
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.
Ideally yes, but we first need a way to flow arbitrary command line arguments to the iOS/Android test apps and that will need some changes in xharness and the iOS/Android test runners, I don't think we need to block the PR on that.
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.
Sounds good. We just need to be conscious that PR validation is running outerloop tests for iOS as well, which might be causing the slow runs.
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.
ah no, we added handling for that already with
runtime/eng/testing/tests.mobile.targets
Line 76 in 3c1b48e
<WriteLinesToFile File="$(PublishDir)xunit-excludes.txt" Lines="$(_withoutCategories.Replace(';', '%0dcategory='))" /> |
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.
Ok, sounds good. Maybe we should do it how we do it in other places passing them as an argument but that is in the future, no need to block this PR.
Looks like it happened again but on the very same machine (dci-macpro-06). I will investigate what's up |
I took the problematic machine offline for investigations so let's see whether the rest goes green now. |
Alright, looks everything is green. So I wonder if we want to check this in or not. The reason is that sometimes the iOS build times out when it is on one of the slow agents (or whatever the reason is), so this will bring flakey-ness. On the other hand, I am not sure whether this is not happening already then? |
I think if we don't check this in we won't find those flaky issues and fix them. However, the question I have is, do we have the capacity yet to enable this on all PRs and CI? |
The capacity for the iOS tests itself is OK. The tests only take 6 minutes right now. We have 59 machines for that and there's 155 of work items so the test itself is usually super short. The capacity for building the iOS tests is coming from AzDO and I am not sure how are we doing there. I will try to find out. |
Building the product and tests took 36 mins in last build which is not bad. |
Practically speaking, what blockers remain on this PR? |
So, from my point of view (and please consider that this is my first and only interaction with
So.. I don't know how flakey the PR builds in Other than that, the iOS tests part seems quite stable and fast, so.. |
We're already seeing this in other OSX, iOS legs and it seems to be an AzDo bug which seems to be under investigation so I wouldn't be concerned by this and also seems like it has somewhat being mitigated.
I still stand my point the best way to mitigate issues is to check-in and investigate issues that come show up.
Given the number of machines you shared above and the time it is taking to process work items it seems fine. We won't know this with certainty until we check it in, and as we enable more test projects and run on more PRs if we hit an issue we can always disable the leg as we did for a couple of days for WASM until we got more capacity. Overall, this LGTM and we should try checking it in, specially since master is already 6.0. |
@premun Please give your approval on the PR and we can merge. |
TARGET_ARCH=$2 | ||
TARGET= | ||
SCHEME_SDK= | ||
[[RunCommands]] |
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.
I'm trying to get rid of the runcommands templating mechanism as having individual runner scripts for different targets (ios/android/wasm) seems to be sufficient. Doing that in #39923. That will basically undo this change here. Any objections?
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.
No, I support that change as we should be able to define it via MSBuild.
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.
No objections from me.
@directhex - any objections?
Forked from #37057
Adds the iOS test leg that will execute selected BCL tests on an iOS x64 Simulator (13.5) using the
OSX.1015.Amd64.Open
queue which is our on-prem Mac Mini infrastructure (60 machines).To prepare the Helix job, we are using the Arcade Helix SDK, more specifically the XHarness Helix SDK which uses the XHarness tool to control the test run.