If we're creating a universal app, and here are satellite assemblies that are not
identical across all RuntimeIdentifiers, those assemblies will be stored in a RuntimeIdentifier-specific
subdirectory during the build.
Unfortunately we didn't know how to find those assemblies at runtime, causing localizations
in universal apps to not work.
This change will:
* Add support for looking in the directory where RID-specific satellite assemblies
are stored.
* Add an assembly resolution event handler to our CoreCLR bridge so that we can
execute our custom lookup code.
* Add an assembly resource lookup test to monotouch-test.
* Add a macOS + Mac Catalyst variation of monotouch-test to xharness that triggers
the bug (a universal test app).
Fixes https://github.com/xamarin/xamarin-macios/issues/16847.
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
Port the availability attribute test from introspection to cecil-tests. It's much
easier and faster to test attributes using Cecil using a desktop executable than
having to execute a test app on each target platform.
This also means that we can make the ApiAvailabilityTest in introspection
legacy-only.
Ref: https://github.com/xamarin/xamarin-macios/issues/10834
While this value isn't used directly in xharness, we can add a
'skip-packaged-macos-tests' label for a PR, which xharness will try to match
with a test label, so the test label must exist, otherwise all tests will
fail.
When the autoformatter runs into the '%...%' pattern in *.cs files, it
will re-format the text (to '% ... %'), but that breaks our text replacement
logic. So instead use a valid C# identifier as a replacement token, in which
case the autoformatter won't confuse our replacement logic.
* Print the load average every 15 minutes. Also print a full process list if
the load average > 10.
* Print a full process list of the system every hour.
* Print a summary to stdout at the end of the test run.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Hopefully this fixes some of the recurrent build problems where we'd fail to
restore nuget packages.
Ref: https://github.com/xamarin/maccore/issues/2620
I wasn't able to execute ilrepack.exe with .NET, so that continues to be
executed with mono.
* Don't load maccore/mk/versions.mk anymore, which means we're not checking
any subsequent dependencies listed in maccore. Note that we still need the
maccore dependency itself for a little while longer.
* Remove some outdated testing code that called into maccore.
* Don't recurse into the maccore directory during make.
* Remove some code checking for ENABLE_XAMARIN that's not used anymore, in
particular in xharness.
This allows the CI to run ALL the tests that the project has in
parallel. This is divided in two main changes:
1. Xharness - We move away from using boolenas to use a flag that states
the tests to run.
2. yaml - We have move the code to use a template per label. This new
jobs all run in parallel and the results are later collected by a
funel job
3. pwsh - Added a new class that understands that we have several mark
downs with the tests results. The classes parses them and them writes
a single comment (and example can be found here: https://github.com/xamarin/xamarin-macios/pull/15201#issuecomment-1162366240
The changes gives the following advantages vs how we used to run tests:
1. The CI run for all tests moves from taking 13 hours to 3/4 hours
(depending on the number of bots in the pool).
2. The download needed to verify the results on a case of failure is
smaller. Rather than downloading several GBs we now just download
that part of the html that we are interested in.
3. Better bot utlization. Bots are just used to a max of 2 hours, this
means that we can use the bots better since they are fragmented.
4. Less VMs. VSDrops has added support for macOS and Linux, we take
advanges of that here.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Collect diagnostic logs from the simulator to try to get better diagnostic information for https://github.com/xamarin/maccore/issues/2558.
Interestingly it seems like just collecting diagnostic information makes the problem much less likely to occur...
Rolf Bjarne Kvinge
Manuel de la Pena