Repository navigation
Add more granular pipelines for mobile configurations #75002
Description
When trying to validate a specific mobile change, we'll manually trigger runtime-extra-platforms to run all tests. This results in running a large swath of configurations that, more often than not, do not need to run. The goal of this issue is to offer more granular pipelines by configuration and determine if we should go deeper (libraries vs runtime tests, for example).
All libraries and runtime tests
- Android emulators
- Android devices
- iOS/tvOS simulators
- iOS/tvOS devices
- MacCatalyst
#74859 can be used for inspiration
Activity
directhex commentedon Sep 2, 2022
So we want
a) not smoke-tests-only. These new pipelines should run all tests. or only run all tests when called directly, otherwise run smoke tests when run as a template include into runtime-extra-platforms?
b) only move the things we're testing in runtime-extra-platforms (e.g. interp vs not, sandbox vs not, AOT vs not, etc etc etc) - don't touch things we're testing in other pipelines like runtime.yml?
directhex commentedon Sep 7, 2022
@steveisok ^^ ?
steveisok commentedon Sep 7, 2022
For mobile, we want to take what's in runtime-extra-platforms and split each configuration into different pipelines.
To answer your questions directly:
a.) yes, the pipelines should run all tests when triggered manually. We don't want to run these on a schedule.
b.) correct
Try moving mobile tests into their own pipelines.
carlossanlop commentedon Sep 8, 2022
@dotnet/area-infrastructure-libraries should we consider doing something similar for runtime libraries legs?
ViktorHofer commentedon Sep 12, 2022
Can you please elaborate on what you mean by that? If I'm not misunderstanding, libraries testing is part of what this issue is tracking.
Try moving mobile tests into their own pipelines. (#75213)
directhex commentedon Oct 3, 2022
Dunno why this wasn't closed with the merge
directhex commentedon Oct 3, 2022
Aha, merged into feature branch not main
Split runtime-extra-platforms into distinct pipelines (dotnet#76328)