Jenkins has a limitation where you can't mark a step a failure, it has to
*fail* to be reported as such.
This means that running multiple tests, and reporting a failure if any of
those tests fail is not possible.
We run into this with the normal test run + the docs tests; where we currently
don't show a red result in the UI if any of those fail.
So incorporate the test-docs step into xharness, so that we only have one
thing to in the Jenkinsfile, which makes it possible for us to fail the test
run step properly.
This also required a few upgrades to xharness to get more info for pull
requests, since the logic to enable the docs tests is a bit more complicated
than anything else we have (if the current branch (or the target branch for a
PR) is 'master' AND xamarin mode is enabled).
We can't share native code between apps and app extensions if the interpreter
settings differ between them, so detect this scenario and automatically
disable native code sharing.
Fixes https://github.com/xamarin/xamarin-macios/issues/5365.
Fixes this:
Errors and Failures:
1) Test Error : Xamarin.iOS.Tasks.CodesignAppBundle("iPhone","Debug").CodesignAfterModifyingAppExtensionTest
System.Exception : Could not determine whether / is APFS or not. 'df -t apfs /' returned 1 and said:
at Xamarin.iOS.Tasks.TestBase.get_IsAPFS () [0x00051] in <c0cbc86394444f8e9cb85adb1eab6fea>:0
at Xamarin.iOS.Tasks.TestBase.EnsureFilestampChange () [0x00001] in <c0cbc86394444f8e9cb85adb1eab6fea>:0
at Xamarin.iOS.Tasks.CodesignAppBundle.CodesignAfterModifyingAppExtensionTest () [0x0007d] in <c0cbc86394444f8e9cb85adb1eab6fea>:0
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) [0x0003b] in <96207d0baa204f48a53ad6be05f5ecba>:0
Fixes this problem:
The following files were modified, and they shouldn't have been:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/src
which shouldn't be reported, since the "file" in question is a directory.
Reference: https://github.com/xamarin/xamarin-macios/pull/5355#issuecomment-452400517
Small optimization. It's not needed to check if the item exists
in the dictionary to remove it, `Remove` returns `true` if the item
was present (but we do not care about the result here).
* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
Fixes this problem when running the VSTS device tests:
Unhandled Exception:
System.Collections.Generic.KeyNotFoundException: The given key 'MONO_SDK_DESTDIR' was not present in the dictionary.
at System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) [0x0001e] in <96207d0baa204f48a53ad6be05f5ecba>:0
at xharness.Harness.LoadConfig () [0x001a3] in <299e29e4a95f41499aef8f7d9863ca3d>:0
at xharness.Harness.Execute () [0x00001] in <299e29e4a95f41499aef8f7d9863ca3d>:0
at xharness.MainClass.Main (System.String[] args) [0x003e3] in <299e29e4a95f41499aef8f7d9863ca3d>:0
including
* Reflection is simply not needed. Existing unit tests
confirms the virtual method are called properly.
* Reduce metadata
* reuse internal delegate types using identical signatures
* remove internnal enum with a single value
* Use `nint` (for `CFIndex`) so it's clearly 64 bits aware (not just
trusting alignment rules)
reference: https://github.com/xamarin/xamarin-macios/issues/5303
* [tests] Add test to ensure LLVM succeeds on watchOS for every assembly we ship.
References:
* https://github.com/mono/mono/issues/12131: LLVM failed for 'UIEdgeInsets.Equals': opcode r4_cneq
* https://github.com/mono/mono/issues/12130: [watchOS] MT3001: Could not AOT the assembly mscorlib.dll
* https://github.com/xamarin/xamarin-macios/issues/4763: [RFC] Improve handling of filter clauses with LLVM/Bitcode
* https://bugzilla.xamarin.com/show_bug.cgi?id=58209: LLVM/bitcode can't handle filter clauses
* LLVM failure in mscorlib.dll is now fixed.
* Revert "LLVM failure in mscorlib.dll is now fixed."
This reverts commit ace3c930a9.
* [tests] Run mtouch tests inprocess.
Fixes a remoting exception:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL fff8ce5c_3219_4dd0_941f_500dd49e02a5/94f23f2_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <dcf627861d9e44ce818b79d685496eeb>:0
Exception rethrown at [0]:
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper(intptr,intptr)
at (wrapper remoting-invoke) NUnit.Engine.Agents.RemoteTestAgent.Load()
at NUnit.Engine.Runners.ProcessRunner.LoadPackage () [0x00040] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.AbstractTestRunner.Load () [0x00000] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner.LoadPackage () [0x0006b] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner..ctor (NUnit.Engine.IServiceLocator services, NUnit.Engine.TestPackage package) [0x0007a] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.TestEngine.GetRunner (NUnit.Engine.TestPackage package) [0x0001e] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.ConsoleRunner.ConsoleRunner.RunTests (NUnit.Engine.TestPackage package, NUnit.Engine.TestFilter filter) [0x00095] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.ConsoleRunner.Execute () [0x000b6] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.Program.Main (System.String[] args) [0x001b5] in <93782c327b3c4ab5aae551528dfe1cae>:0
* [xharness] Run mtouch tests in-process.
* [tests] Don't run the LLVM watchOS tests if we didn't build for device.
* [tests] Update NoLLVMFailuresInWatchOS known failures according to latest mono bump.
Also run 'make bgen' after the build to install any newly built binaries, so
that the generator tests that don't use the in-proc generator automatically
pick up the newly built one.
Even if 'supportedVideoFormats' is static the type is abstract.
> Important
> ARConfiguration is an abstract base class, so its implementation of
> this property always returns an empty array. Read this property from
> the configuration subclass you plan to use for your AR session, such
> as ARWorldTrackingConfiguration or ARFaceTrackingConfiguration.
https://developer.apple.com/documentation/arkit/arconfiguration/2942261-supportedvideoformats?language=objc
and this behave differently in Objective-C (than .net) as every (static)
method will be different (and not a single implementation like C#).
The existing implementation (as a property) calls `ARConfiguration`
implementation which simply throws a (native) exception
> NSInvalidArgumentException Reason: Supported video formats should be called on individual configuration class
The solution is to obsolete the property (can't be subclassed in .net
since it's static) and add, only on the subclasses, a method that
call the 'supportedVideoFormats' selector on the current (not base)
type.
Added unit test to detect the addition of newer subclasses - since they
will also need to expose this method.
reference: https://github.com/xamarin/xamarin-macios/issues/5347
Basic fix that does not require a breaking change.
It's _basic_ as it does not fix the performance comments made inside
the issue. Those are different (not a bug, an enhancement) and I'll
file a separate issue to track this.
Reference: https://github.com/xamarin/xamarin-macios/issues/5132
This PR adds support to the use of *.ignore files for iOS/tvOS/WatchOS. The files are very similar to those that are use in xtro. We have:
* common-{TestProjectName}.ignore: For those tests that fail in all platforms.
* tvOS-{TestProjectName}.ignore: For tvOS specific failures.
* watchOS-{TestProjectName}.ignore: For watchOS specific failures.
* iOS-{TestProjectName}.ignore: for iOS specific projects.
Two test projects that were ignored previously have been added to show that the code does as advertised:
* SystemDataXunit: xUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1131
* SystemServiceModelWebTests: NUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1137
The files take the name of the failing tests, although we do support ignoring by class/namespace and other combinations, that would make the *.ignore files format more complicated and it is not worth it.
objc_msgSend*_stret doesn't exist on arm64, so trying to call these functions
in our generated P/Invoke wrappers will result in a clang error:
[...]/pinvokes.m:180:69: error: 'objc_msgSend_stret' is unavailable: not available in arm64 (TaskId:243)
So instead generate a call to throw an EntryPointNotFoundException (which is
exactly what would happen if we didn't generate the P/Invoke wrapper).
Fixes https://github.com/xamarin/xamarin-macios/issues/5183.
Only the arm64 slice are built for iOS 7.0 (because that's when arm64 was
introduced), the arm7(s) slices are built for iOS 6.0, which means it's safe
to ignore this warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/5092.
Hopefully fixes these tests:
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchBundleResource: Expected: not 2018-12-18 17:15:05.000
But was: 2018-12-18 17:15:05.000
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchEmbeddedResource: Expected: not 2018-12-18 17:15:07.000
But was: 2018-12-18 17:15:07.000
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchStoryboard: Expected: not 2018-12-18 17:15:09.000
But was: 2018-12-18 17:15:09.000
Additionally change existing sleeping code to not sleep when running on APFS.
Should make test runs slightly faster.
* [runtime] Only print the stack trace if we have a stack trace.
* [runtime] Only print 'Unhandled managed exception' when it's actually an unhandled exception.
We render exceptions in several other circumstances, when they're not
unhandled, so this improves the output text in those scenarios a little bit.
* [runtime] Fix typo in logging message.
* [runtime] Improve abort message for managed exception marshalling a bit.
Fixes these test failure:
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True): #RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined Objective-C class: MDLTransform. The symbol '_OBJC_CLASS_$_MDLTransform' could not be found in any of the libraries or frameworks linked with your application.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True): #RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined Objective-C class: MDLTransform. The symbol '_OBJC_CLASS_$_MDLTransform' could not be found in any of the libraries or frameworks linked with your application.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
This makes Visual Studio for Mac show a better error message when the system mono is too old:
FATAL ERROR [2018-12-19 08:07:50Z]: Visual Studio failed to start. Some of the assemblies required to run Visual Studio (for example gtk-sharp)may not be properly installed in the GAC.
System.Exception: Toolkit could not be loaded ---> System.NotSupportedException: This version of Xamarin.Mac requires Mono 5.18.0.185, but found Mono 5.16.0.209.
at ObjCRuntime.Runtime.VerifyMonoVersion () [0x000b4] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Runtime.mac.cs:150
at ObjCRuntime.Runtime.EnsureInitialized () [0x00030] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Runtime.mac.cs:117
at AppKit.NSApplication.Init () [0x00016] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:56
at Xwt.Mac.NSApplicationInitializer.Initialize () [0x00051] in /work/monodevelop/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/NSApplicationInitializer.cs:44
at Xwt.Mac.MacEngine.InitializeApplication () [0x00001] in /work/monodevelop/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/MacEngine.cs:48
instead of (from https://github.com/mono/monodevelop/issues/6779):
FATAL ERROR [2018-12-17 14:05:44Z]: Visual Studio failed to start. Some of the assemblies required to run Visual Studio (for example gtk-sharp)may not be properly installed in the GAC.
System.Exception: Toolkit could not be loaded ---> System.NullReferenceException: Object reference not set to an instance of an object
at (wrapper managed-to-native) System.Object.wrapper_native_0x102f47470()
at ObjCRuntime.Runtime.EnsureInitialized () [0x00041] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.6.0.1/src/Xamarin.Mac/ObjCRuntime/Runtime.mac.cs:118
at AppKit.NSApplication.Init () [0x00016] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.6.0.1/src/Xamarin.Mac/AppKit/NSApplication.cs:56
at Xwt.Mac.NSApplicationInitializer.Initialize () [0x00046] in /Users/vsts/agent/2.144.0/work/1/s/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/NSApplicationInitializer.cs:44
at Xwt.Mac.MacEngine.InitializeApplication () [0x00000] in /Users/vsts/agent/2.144.0/work/1/s/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/MacEngine.cs:48
When `HttpClient` is used it might not be possible to set custom
properties on the handler.
This PR avoids a fight between the `HttpClient.Timeout` and the ones that
`NSURLSession` provides - making its use, as default, working as expected
It is still possible to set those custom properties when creating the
`NSUrlSessionHandler` manually, so there's no loss of functionalities.
Adding a unit test would be tricky since it depends on external sites and
requires "enough" delays to trigger (both leading to false positives over
time).
Notes
* HttpClientHandler timeout is broken -> https://github.com/mono/mono/issues/12100
* CFNetworkHandler is broken when no data is received -> https://github.com/xamarin/xamarin-macios/issues/5289
Fixes https://github.com/xamarin/xamarin-macios/issues/5190
* [msbuild] Adds output property for unpacked resources
This output property will be used by VS to create/touch output files on Windows only for the unpacked resources and not for all the resources found.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
* [msbuild] Adds output property with copied frameworks to MTouchTaskBase
This property is needed from VS to know Frameworks where changed as a result of the mtouch execution. The lack of this information was causing MSBuild to skip the CodesignFrameworks target (from Windows) on incremental builds if the frameworks were copied to the app bundle by mtouch.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
We now download the ios Mono sdk which means that there is no need for
us to build the test assemblies on iOS, WatchOS and tvOS BUT we need to
do so for the Mac tests.
The change includes:
1. Use fo the downloaded test assemblies.
2. Removal of the dependency of building them in the tests.
3. Move back to using reflection for the project generation.
4. Remove the cached project details added in the workaround.
* [builds] Consume LLVM from mono's package.
* Fix mono sdk paths in makefile to be relative to the top.
* [builds] Make curl verbose if V=1.
* [builds] Improve llvm build targets.
* Fix dependencies so that 'make -j llvm' (and other variations of the same
target) work properly.
* Rename things a bit to make it clear there are 32-bit and 64-bit llvm
targets.
* [builds] Consume cross compilers from mono's package as well.
Compiling the cross compilers while using LLVM from mono's package becomes
complicated, so just go ahead and get the cross compilers from the mono
package as well.
* Make llvm rules symmetric between llvm32 and llvm64.
The MessageHandler class suffers from the CVE 2018-8292. this commit
fixes the issue by ensuring that the we donot use autoredirect from
CFNetwork and perform the first request. If the response is a redirect,
follow it wihout the Autherization headers.
Sebastien Pouliot
Manuel de la Pena
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Cody Russell
Filip Navara
Matt Sylvia
Chris Hamons