Should fix this (or at the very least not prevent xharness from writing out the report):
21:07:30.3947450 Failed to write log: System.IO.FileNotFoundException: Could not find file '/Users/builder/Library/Logs/CoreSimulator/6DA2ED3C-B1FA-4D0B-9DD6-113E5F9A1381/system.log'.
File name: '/Users/builder/Library/Logs/CoreSimulator/6DA2ED3C-B1FA-4D0B-9DD6-113E5F9A1381/system.log'
at System.IO.__Error.WinIOError (System.Int32 errorCode, System.String maybeFullPath) [0x00207] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/io/__error.cs:188
at System.IO.FileInfo.get_Length () [0x00038] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/io/fileinfo.cs:171
at xharness.CaptureLog.Capture () [0x0004a] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Log.cs:334
at xharness.CaptureLog.Flush () [0x00008] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Log.cs:373
at xharness.Jenkins.GenerateReportImpl (System.IO.Stream stream, System.IO.StreamWriter markdown_summary) [0x017db] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Jenkins.cs:2012
at xharness.Jenkins.GenerateReport (System.Boolean only_if_ci) [0x00075] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Jenkins.cs:1313
There seems to be an issue where adding stuff to the TCC.db might fail
partially. In that case we try again, but we try to add every entry once more,
which now might fail due to existing entries.
So always replace when adding new entries in TCC.db. Also dump the database
when done to help debugging if it turns out this doesn't fix maccore#915.
Might fix https://github.com/xamarin/maccore/issues/951.
* [jenkins] Only XM apps with variations are Classic/32-bit apps, so adjust ignore logic accordingly. Fixes maccore issue 884.
Fixes https://github.com/xamarin/maccore/issues/884.
* [mmp] Fix passing -stdlib=libc++ to clang.
* [tests] Fix 32-bit XM issues.
* [xharness] Add support for building 32-bit XM apps by using Xcode 9.4.
* [xharness] Since xharness can now build 32-bit mac apps, enable them by default.
* Remove debug code.
* Remove unused variable.
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.
This fixes a NullReferenceException when there are already paired watch devices:
[0x700009ad7000:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
"<unnamed thread>" tid=0x0x700009ad7000 this=0x0x10b903ad8 , thread handle : 0x7f9ad49109a0, state : not waiting
at xharness.Simulators/<CreateDevicePair>d__18.MoveNext () [0x001ae] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:169
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.Start<xharness.Simulators/<CreateDevicePair>d__18> (xharness.Simulators/<CreateDevicePair>d__18&) [0x0002c] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at xharness.Simulators.CreateDevicePair (xharness.Log,xharness.SimDevice,xharness.SimDevice,string,string,bool) [0x00057] in <7c5e77efeb3146c095a26043fb517189>:0
at xharness.Simulators/<FindOrCreateDevicePairAsync>d__19.MoveNext () [0x000fc] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:206
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.Start<TStateMachine_REF> (TStateMachine_REF&) [0x0002c] in <0f9df4881040473f9da7cf6c2e2cb8c3>:0
at xharness.Simulators.FindOrCreateDevicePairAsync (xharness.Log,System.Collections.Generic.IEnumerable`1<xharness.SimDevice>,System.Collections.Generic.IEnumerable`1<xharness.SimDevice>) [0x0003f] in <7c5e77efeb3146c095a26043fb517189>:0
at xharness.Simulators/<FindAsync>d__20.MoveNext () [0x00364] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:275
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
Detect if we failed to create a simulator device pair due to trying with a
watch that's already paired. We were already detecting this scenario if the
watch was a member of an available pair, but not if the watch was a member of
an _unavailable_ pair (since mlaunch doesn't list unavailable device pairs).
So detect this scenario from the error message simctl gives us instead, and in
that case create a new watch device and try to create the pair again.
Fixes https://github.com/xamarin/maccore/issues/830.
* [xharness] Create simulators if they don't already exist.
Create any needed simulators, instead of relying on them already existing (or
someone manually creating them).
A nice side effect is that it will become possible to delete all simulators on
a bot (to reclaim space), and they'll be re-created when needed.
* [xharness] If a watch device is already paired, create a new watch device and pair that instead.
This will make xharness not listen for tests to connect forever, decrease the
number of threads needed, and as well not print loads of aborted messages when
xharness exits:
SimpleTcpListener: an exception occurred in processing thread: System.Threading.ThreadAbortException: Thread was being aborted.
at xharness.SimpleTcpListener.Start () [0x0009d] in /Users/XamarinQA/vsts/_work/1/s/tests/xharness/SimpleTcpListener.cs:44
at xharness.SimpleListener.<StartAsync>b__41_0 () [0x00002] in /Users/XamarinQA/vsts/_work/1/s/tests/xharness/SimpleListener.cs:93
Hopefully fixes an issue with monotouch-test randomly running into permission
dialogs because xharness failed to fix TCC.db because it gave up too early.
* [runtime] build interp-, icalltable- and ilgen libraries so they can be consumed in interpreter configuration
* [mtouch] add --interpreter configuration support
* [xharness] Add support for removing defines from cloned project files.
* [xharness] Run monotouch-test, mscorlib and mini tests with the interpreter too.
They're ignored for now, which means we won't run them on the bots.
* [mtouch] We're using dlsym when using the interpreter.
* [xharness] enable mini regression tests with interpreter on CI
* [tests] Determine at runtime instead of compile time whether LinkAll is enabled. Fixes#3812.
This way we can remove the LINKALL define, which also means nobody can forget
to define it when building using LinkAll.
https://github.com/xamarin/xamarin-macios/issues/3812
* [build] Remove MT.D source build and replace it with a binary
This commit removes MonoTouch.Dialog from our source build and
replaces it with a binary from c913506df2/MonoTouch.Dialog-Unified
The MT.D hash used in this commit is fixed to migueldeicaza/MonoTouch.Dialog@92c6e14
* Update .gitignore.
* MonoTouch.Dialog-1.dll doesn't need depend on the platform assembly anymore, because we're copying a binary instead of building.
* Add significant debug spew.
* More debugging.
* Remove debug spew.
* [compare-commits] Create directory before trying to create files in it.
Make sure to override all required TextWriter methods so that the LogFile gets
all the output any writers (such as the XmlWriter that is used to create the
html report for NUnit tests by applying an XSLT transform to the xml results)
writes.
* Put a binary copy of mlaunch in macios-binaries instead of in Azure. Fixes#3316.
If the Xamarin build is enabled, then build mlaunch from source, otherwise get it from macios-binaries.
Fixes#3316.
* Bump macios-binaries.
Commit list for xamarin/macios-binaries:
* xamarin/macios-binaries@69a9088 Bump mlaunch to xamarin/maccore@4505cd6f02 (#8)
Diff: e1e8bdf7a8...69a90882a0
* make msbuild/ after tools/.
Build msbuild/ after tools/, so that mlaunch builds when building from source,
since its build needs the MSBuild logic installed by msbuild/.
* Bump macios-binaries to get Xcode 9.3-capable mlaunch.
* Put a binary copy of mlaunch in macios-binaries instead of in Azure. Fixes#3316.
If the Xamarin build is enabled, then build mlaunch from source, otherwise get it from macios-binaries.
Fixes#3316.
* Bump macios-binaries.
Commit list for xamarin/macios-binaries:
* xamarin/macios-binaries@69a9088 Bump mlaunch to xamarin/maccore@4505cd6f02 (#8)
Diff: e1e8bdf7a8...69a90882a0
Currently we consider the failed **and** the skipped tests as failures which is confusing. The tests didn't all "fail" because some were just not ran.
This PR updates the summary message to be a little more clear.
The F# compiler complains that:
/Users/xamarinqa/vsts/_work/52/s/tests/fsharp/Main.fs(13,9): error FS0433: A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence.
Main.fs is the last file in the project file, but the MSBuild tasks adds
another one at the end:
obj/iPhone/Debug64-today-extension/Xamarin.iOS,Version=v1.0.AssemblyAttribute.fs
because we're building a library (in which case the MSBuild tasks assume that
there won't be any Main functions in the project, and as such it's safe to
append files to compile).
Work around this by excluding the Main function from F# extensions, it's not
needed anyway.
This fixes an issue where multiple copies of the GuiUnit project would have
the same output directory, causing random problems when building those
projects in parallel.
* [tests] Don't run mmp regression tests in parallel. Fixes maccore #645.
For some reason vstool becomes confused and starts erroring out if multiple
vstools are running at the same time.
So work around this by executing the MMP regression tests serialized.
Fixes https://github.com/xamarin/maccore/issues/645.
* [xharness] Upload the logs from the mmp regression tests.
Rolf Bjarne Kvinge
Sebastien Pouliot
Vincent Dondain
Alex Soto
Bernhard Urban
Sebastien Pouliot