Add code to write the TestReport when we have xunit results. Also
refactored code for the NUnit format to not use LINQ, it will use less
memory and in the future we can move to async (not now since it might
raise other problems).
fixes: https://github.com/xamarin/xamarin-macios/issues/7826
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We ping the tcp listener to know that we have a tcp connection, that is
written in the xml logs, which means that parsing will not work. Ignore
the ping, parse xml, and make sure that the xml that will be consume by
vsts is valid.
This PR also fixes https://github.com/xamarin/maccore/issues/827 which does not longer happen.
Looks like we have issues with the internet sharing in the VSTS bots,
this means that now that we always try to parse the XML on CI, we get an
exception, catch it and do not show the results.
The workaround simply tries to read the xml, if possible, we will parse
it, else deal with the text only log. The fix will show the results, but
it is a workaround for a configuration issue in the CI.
Unify the harness properties to just look at InCI and remove all the
other ones. There is no real need to have differences between jenkins
and VSTS and Wrench is gone.
We used to test only on Jenkins, and if the build version had jenkins on
it, rather than doing so, just check if we are in the CI by looking if
BUILD_REVISION is present in the env.
Use the xml parsing helper methods to decide if the xml can be parsed
and if we will be able to generate the report. That way we avoid an
exception that makes the CI noise.
* [XHarness] If there are issues generating the BCL tests for mac dont crash.
* [xcode11.3][mono] Use the right mono branch 2019-08 to sync with android
* Allways build from source.
* Revert "Allways build from source."
This reverts commit 09b7a4c432.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
After this commit we will have more application but they will be the
appropiate size so that they can be built with the linker for iOS 32b.
It is important to note that the following apps WILL CONTINUE to fail
since the dlls need to be splitted in mono:
* mscorlib tests
* Mono BCL tests group 5 - Which is monotouch_System.Core_xunit-test.dll
and is too large.
If forcing a managed type for a particular native handle, we must ensure we're
always successful.
This means creating another managed instance even if there already is an
existing instance for the native handle. This is not optimal, but the
alternative is worse: some functionality can be completely broken otherwise
(such as NSSavePanel⁄NSOpenPanel may stop working).
If creating multiple managed instances for the same native handle ends up
being too problematic, we'll probably have to add full support for this
scenario (see #7442).
Fixes https://github.com/xamarin/xamarin-macios/issues/7441.
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
The latest SDK version and the latest OS version does not necessarily have to
match (for instance the iOS 13.2 SDK can support both iOS 13.2 and iOS 13.3),
so keep track of them separately.
Also use the latest OS version to determine which simulator to run, instead of
the latest SDK version (Xcode 11.3 ships with the iOS 13.2 SDK but only has an
iOS 13.3 simulator, not an iOS 13.2 simulator).
Fixes https://github.com/xamarin/maccore/issues/2066.
* Bump for Xcode 11.3 beta 1
* [system-dependencies] Make it clearer what failed on the bots.
Locally we use colors to distinguish between warnings and failures, but colors
don't show up on the bots, so use text instead.
* Verbose provisioning.
* [system-dependencies] Improve simulator checks a bit.
* Non-verbose provisioning.
The initial solution fixed the rance condition in which the index
changed, but that did not guarantee that we would get the correct
bundles. We now clone the CFArray (which also clones the callbacks set
to the array) and iterate over it to make sure Apple does not do evil
tings while we are iteraing.
Better Fixes: https://github.com/xamarin/maccore/issues/940
When working on https://github.com/xamarin/maccore/issues/940 we noticed
that clone the array would be a better approach.
The CFArrayCreateCopy add some nice things:
* The pointer values from theArray are copied into the new array.
* The values are also retained by the new array.
* The count of the new array is the same as theArray
* The new array uses the same callbacks as theArray. [IMPORTANT]
Whith this in, we can have a better fix for https://github.com/xamarin/maccore/issues/940
* [Packaging] Ensure that when we build from source, the srcs go to the correct plance.
When building from source, the install-sources command was not moving
the files correctly. This change makes sure that, if we build from
source, we do add the mono sources in the correct location.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7393
The PathManglerFactory was getting confused when building mono from
source again and since it did not find the sources in the download
directory it considered that the path to modify was part of Xamarin.
Now the factory tests first if we are getting a path from the mono
external submodule, if that is the case we know is a mono path and do
the right thing.
Fixes https://github.com/xamarin/maccore/issues/2053
The PathManglerFactory was getting confused when building mono from
source again and since it did not find the sources in the download
directory it considered that the path to modify was part of Xamarin.
Now the factory tests first if we are getting a path from the mono
external submodule, if that is the case we know is a mono path and do
the right thing.
Fixes https://github.com/xamarin/maccore/issues/2053
Manuel de la Pena
monojenkins
Sebastien Pouliot
Alex Soto
Vincent Dondain
Rolf Bjarne Kvinge
Pramit Mallick
Waleed Chaudhry