Add support for the 'run-internal-tests' label on pull requests to indicate
that the internal jenkins should run tests when that label is applied.
Also make it so that either the 'run-internal-tests' or the 'build-package'
label will actually make the internal jenkins execute (otherwise the 'run-
internal-tests' label would also require the 'build-package' label, which
wouldn't be very obvious/user-friendly).
Creating a new NSString doesn't always lead to creating a new NSString, which
will obviously cause trouble.
The scenario is:
* An NSString with the value @"Bye" is added to an NSDictionary, with the same
string as both the key and the value.
* The (managed) string indexer is used to try to get the value back. The
string indexer would call 'new NSString ("Bye")', which would create a new
managed NSString, and maybe a new native NSString (or maybe it would re-use
an existing NSString). Then the handle of this NSString would be passed to
the native API, and the same handle would come back as the result (since the
same string is both the key and the value). We'd call Runtime.GetNSString on
the returned handle, get back the same managed instance that was created
just before the call to the native method. Finally, just before returning
this managed instance from the indexer, we'd dispose it... since it was
created in a 'using' block. Then we'd return a disposed NSString object from
the indexer. Ops.
The fix is to not create a managed wrapper for the NSString handle we need to
pass to the native API, but create and free the native NSString object without
using a managed wrapper.
This can be useful when working on the support for private jenkins, since many
of those changes can only be tested as a pull request, and they also tend to
include a lot of commits (because nothing can be tested locally).
So until whatever needs implementing for private jenkins is complete and
working, there's no need for the public bots to do anything for such pull
requests.
Mostly known iOS cases that are now part included in macOS.
Two failures remains until the AppKit update is merged, i.e.
both were _upgraded_ to conform to `NSSecureCoding`
```
[FAIL] NSBezierPath conforms to NSSecureCoding but does not implement INSSecureCoding
[FAIL] NSGradient conforms to NSSecureCoding but does not implement INSSecureCoding
```
Nothing really new beside the OpenGL related deprecation and the fact
that 3 fields were removed, without deprecation, and this requires some
adjustments in the intro tests (while running on 10.14) to ignore them.
1) ApiFieldTest.FieldExists (Introspection.MacApiFieldTest.ApiFieldTest.FieldExists)
3 errors found in 5680 fields validated: QCCompositionInputRSSArticleDurationKey, QCCompositionInputRSSFeedURLKey, QCCompositionProtocolRSSVisualizer
Expected: 0
But was: 3
at Introspection.ApiFieldTest.FieldExists () [0x00127] in /Users/poupou/git/xcode10/xamarin-macios/tests/introspection/ApiFieldTest.cs:245
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in /Users/poupou/git/xcode10/xamarin-macios/external/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:305
2) ApiFieldTest.NonNullNSStringFields (Introspection.MacApiFieldTest.ApiFieldTest.NonNullNSStringFields)
3 errors found in 4904 fields validated: QuartzComposer.QCComposition.InputRSSArticleDurationKey, QuartzComposer.QCComposition.InputRSSFeedURLKey, QuartzComposer.QCComposition.ProtocolRSSVisualizer
Expected: 0
But was: 3
at Introspection.ApiFieldTest.NonNullNSStringFields () [0x0008d] in /Users/poupou/git/xcode10/xamarin-macios/tests/introspection/ApiFieldTest.cs:214
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in /Users/poupou/git/xcode10/xamarin-macios/external/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:305
That issue is filed w/Apple https://bugreport.apple.com/web/?problemID=41125938
1. Put xtro's results in a subdirectory of the current test's log directory,
not a sibling directory of the root log directory (which would prevent it
from being uploaded after a test run, since only the root log directory is
uploaded).
2. Just add the existing index.html as the html report to the collection of
logs, no need to create a new file pointing to it. This fixes a problem
where the generated html file would redirect to a local file, which would
not work when served from a web server.
It seems Cecil doesn't search next to the current assembly for any assembly
references, which means that it may fail to resolve assemblies in certain
circumstances:
Failed files
Expected: <empty>
But was:
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/2.1/OpenTK.dll: Failed to resolve assembly: 'monotouch, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.TVOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.TVOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'"
However, Cecil does search the current directory by default, so before loading
any assemblies, change the current directory to the directory of the assembly
we're loading.
Fixes https://github.com/xamarin/xamarin-macios/issues/4241.