[CI] Add some extra params to configure the test templates. #7955
Conversation
build-tools/automation/yaml-templates/stage-msbuild-emulator-tests.yaml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I am wondering if it makes sense to put test jobs for MAUI dependencies in the unified pipeline... I don't think we plan on moving test jobs out of our pipelines, and we're already struggling with machine resources for many of our test jobs. I think it may be better for the unified pipeline to run all of the MAUI tests and any MAUI integration tests we have, rather than duplicate existing test runs from its dependencies.
Maybe we can continue to run non-MAUI tests in the individual product repos, and instead add some manual intervention / sign off to the end stages of the unified pipeline where product owners could approve specific commits?
|
My take on this and we all can discuss further, is that if we are resource constrained we definitely need to address this by requesting the hardware we need in the labs. I think there is a ton of value having these tests in the unified pipeline as we will have one stop for all the tests done in the bits that we intend to ship and insert so there is no doubt on the quality of our releases. Resource wise this should not be much of a burden as we can initially use the unified pipeline for our release branches. I agree that we can have test rings and we can split testing as we see fit, but the testing capability must be present in the mega pipeline since the beginning else we will keep piling backlog and this work is supposed to help to increase the confidence on our builds all the way. |
I don't think duplicating existing PR checks is going to have an impact on our confidence in the quality of a given set of builds, we have a plenty of gaps to fill elsewhere in this regard. The machine pool availability concern is primarily a result of the fact that the unified pipeline runs for every commit to every release branch of every product repo. While that run is batched, it will still increase demand on our infrastructure quite a bit (there were ~16 builds today alone). I'm having a bit of difficulty seeing how the value outweighs the cost, even if we had infinite capacity. |
| stageCondition: succeeded() | ||
| depensOn: mac_build |
There was a problem hiding this comment.
| depensOn: mac_build | |
| dependsOn: mac_build |
Same
We can have the possibility and ignore them, that is not an issue. We just want to have the template added to the pipeline, if the resources are an issue, it can be disabled the same way it is in the macios tests. |
* main: Bump to xamarin/Java.Interop/main@554d819 (dotnet#7951) [Microsoft.Android.Sdk.ILLink] fix crash when TZ changes (dotnet#7956) [tests] Port 'Xamarin.Android.JcwGen-Tests.JcwGen-Tests' to .NET (dotnet#7949) [Xamarin.Android.Build.Tasks] remove `pdb2mdb` (dotnet#7950) [ci] Add some extra params to configure the test templates (dotnet#7955) Convert `/tools` and `/build-tools` projects from `net472` to `$(DotNetStableTargetFramework)` (dotnet#7943) [Xamarin.Android.Build.Tasks] fix cases of missing `@(Reference)` (dotnet#7947) Bump com.android.tools:r8 from 4.0.52 to 8.0.40 (dotnet#7934) Bump to xamarin/Java.Interop/main@a172402 (dotnet#7944) [Xamarin.Android] Remove OpenTK, sqlite-xamarin, System.EnterpriseServices. (dotnet#7940) [ci] Stop building classic test suites. (dotnet#7938) Bumping to the correct monodroid commit Trying to bump monodroid to run debugger-tests Pass timeout to runtime
* main: Bump to xamarin/Java.Interop/main@554d819 (dotnet#7951) [Microsoft.Android.Sdk.ILLink] fix crash when TZ changes (dotnet#7956) [tests] Port 'Xamarin.Android.JcwGen-Tests.JcwGen-Tests' to .NET (dotnet#7949) [Xamarin.Android.Build.Tasks] remove `pdb2mdb` (dotnet#7950) [ci] Add some extra params to configure the test templates (dotnet#7955)
No description provided.