If the pipeline is set on debug, to be able to see any issues, propagate
that to the make calls so that we can also get the information there,
else debugging issues with the pipelines + make is really hard.
Some of the bots fail to do the checkout (miss configuration). The clean
up step is always executed and assumes the pressence of a script, which
will fail since the script is not there.
The script is small, there is no need to add the rm in an extra file
that needs to be checkout.
This removes an extra warning that is set in the pipeline which is noise
when monitoring.
If the bot could no get the provisioning profiles installed, there is no
reason for certain tasks to run since they are all going to fail. This
adds A LOT of noise in the pipeline for the monitoring person to check
when there is no reason.
Move to use a template for the DDFun pipeline. Copy the current pipeline
to a template, set some parameters and recreate the pipeline importing
the template.
* [master] Bump mono to pickup needed nunitlite changes.
Commits are:
* [interp] context can be uninitialized for get_resume_state callback (#18535) mono/mono@455cf7d
* [2019-12] [debugger] Native thread not executing managed code considered as terminated (#18504) mono/mono@a979811
* [jit] Compute has_references correctly for gshared types whose constraint is a generic valuetype. Also emit write barriers correctly for these types. (#18562) mono/mono@f9e5a6d
* [2019-12] Bump msbuild to track mono-2019-10 (#18577) mono/mono@01be275
* [runtime] Disable lldb backtrace display on osx, it hangs on attaching in lldb. (#18591) mono/mono@ef8188a
* configure.ac: remove AC_SEARCH_LIBS for libintl (#18595) mono/mono@e55302c
* Bump bockbuild for Pango patch 1e2d68b
* [corlib] Split corlib xunit tests even more for iOS (#18620) mono/mono@8b72dbb
* [2019-12] [merp] MONO_DEBUG=no-gdb-stacktrace shouldn't disable MERP (#18611) mono/mono@4c93e38
* [aot] Avoid inflating gparams with byreflike types during generic sharing. (#18682) mono/mono@0011444
* Update deprecated query parameter to header (#18705) mono/mono@e65846b
* [NUnitLite] Bump nunitlite submodule. (#18733) mono/mono@36073a0
Diff: 2edccc52a7...36073a0c74
Other commits need for this to land"
* Add a MONO define so that we get the extensions written for mono.
* Update the sources on iphone to remove the TextUI which is not used.
* BONUS: Remove an annoying warning when compiling NUnitLite
* Update the templates too which are use by xharness.
```
warning CS0659: 'ResultState' overrides Object.Equals(object o) but does not override Object.GetHashCode()
```
When building extensions, we first store all the mtouch arguments in a file
when msbuild builds the extension, and then when msbuild builds the main
project, we load those arguments again and actually build the extension at the
same time as we build the main app.
As such, it's important to make sure that when we reload the extension
arguments we end up with the exact same build configuration as the first time.
Unfortunately that was not the case regarding the interpreter: we
automatically set the 'EnableRepl' value in Main according to whether the
interpreter was enabled or not, but Main is not called after re-loading the
arguments when building extensions.
Fix this by moving the logic that automatically sets 'EnableRepl' to somewhere
that is executed when re-loading arguments when building extensions.
Fixes https://github.com/xamarin/xamarin-macios/issues/7780.
* [registrar] Fixes NSString trampoline code generation in static registrar
Fixesxamarin/xamarin-macios#7733
This was introduced as a side effect of commit 8425129, we
used to generate `id foo` instead of the full block signature
in the trampoline code used by the static registrar, this is
the reason we never caught this condition before.
Added registrar test.
* Move tests to the appropiate test file
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
- https://github.com/xamarin/xamarin-macios/issues/5738
- There are a number of managed exceptions Apple can throw at you during
debugging, such as expanding a NSColor in the wrong colorspace
- Throwing a managed exception is a nicer debugging experience, and
during debug we don't care about any performance penality.
TL&DR
* re-apply the fix to cache.cs from https://github.com/xamarin/xamarin-macios/pull/7544
* which was reverted in https://github.com/xamarin/xamarin-macios/pull/7589
* since it regressed mscorlib/sim testing in xharness (for other reasons)
* Final part to fix https://github.com/xamarin/xamarin-macios/issues/7514
This was the ~night~ day before christmas... amd a tough nut to crack!
Thanksfully we had a good test case (inside #7514) and then xharness
regressed one test in consistent, reproducible manner.
xharness builds mscorlib tests twice (32 and 64 bits) even if it's a
fat application (could be reused). That should not be a huge problem
since the 2nd build should be identical and the cache should be (re)used.
An earlier attempt fixed this (comparison was true for the wrong
reasons [1]) but the fix did not end up with the same arguments !?! and
was reverted.
This is the diff between the first and second builds:
```diff
--- /Users/poupou/a.txt 2019-12-23 09:55:01.000000000 -0500
+++ /Users/poupou/b.txt 2019-12-23 09:55:01.000000000 -0500
@@ -182,5 +182,5 @@
-r=/Users/poupou/git/xamarin/xamarin-macios/builds/downloads/ios-release-Darwin-8f396bbb408b5758fccb8602030b9fa5293ce718/ios-bcl/monotouch/tests/Xunit.NetCore.Extensions.dll \
' --target-framework=Xamarin.iOS,v1.0' \
--root-assembly=/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/bin/mscorlib/iPhoneSimulator/Debug-unified/com.xamarin.bcltests.mscorlib.exe \
- ' -v -v -v -v' \
+ ' -v -v' \
@/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/obj/iPhoneSimulator/Debug/response-file.rsp \
```
Since they are not identical the cache is invalidated (which is normal,
cache-wise) and produce an output app that is incorrect (and crash
32bits).
Now there is code to ignore verbosity options (both `-v` and -q`) since
they will not affect what `mtouch` generates. However this was broken
because mtouch's response-file parser is quite basic and stricter the the
specification
spec: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/response-file-compiler-option
issue: https://github.com/xamarin/xamarin-macios/issues/7644
That failed in two different ways
1. note the extra space before the first `-v` in the diff (before the `'`
quote). That skipped the line.
2. there are multiple `-v` in the same line, again that make the
filtering skip the line.
*Unknowns*
It's too close to xmas/vacation so I might not find the reasons/issues
for the following, unanswered questions...
1. Why is the re-build app bundle failing at runtime when p/invoking ?
Something is not regenerated (symbol maps?) ?
2. Why xharness 2nd build has more verbosity than the first one (likely
harmless) ?
[1] the original cache.cs issue (prequel)
issue w/test case: https://github.com/xamarin/xamarin-macios/issues/7514
first attempt: https://github.com/xamarin/xamarin-macios/pull/7544
While incorrect the first attempt to fix `cache.cs` was a logical, if
not entirely complete, fix. Without it this is what we _currently_ cache:
```
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mtouch/mtouch.exe \
```
and that does not include any of mtouch's arguments, that can change
between executions and (should) invalidate the cache.
In this case it means the cache is used (no difference) but this does
**not** parse the content of the **response file** which is obviously
wrong (and we do have code to process it).
On the original issue's test case this is what makes the difference
between using the same *old* nuget assembly after an update (and fail)
by itself and also because the updated framework was not copied (due
to the 2nd part of the bug report wrt `copyfile`).
OTOH re-using (incorrectly) the cache is what makes xharness's mscorlib
unit tests works right now :(
Inspiration was taken from other yaml pipelines but those multiple jobs are not behaving the way I expected.
1. Each job will clone `xamarin-macios` in a dedicated folder (for 3 jobs you'll have `./1/s`; `./2/s`; `./3/s`)
2. The goal of the last job was to upload the `TestSummary.md` but because of the cloning strategy it couldn't find it. There might be ways to pass files (artifacts?) between jobs but there's no need to be that fancy right now.
3. Cloning takes time so I'm assuming having everything in one job can actually save us some time.
- We had `./jenkins/vsts-device-tests-set-status.sh: line 88: HTML_REPORT: unbound variable` in the `Report results to GitHub as comment / status` step. Now that the HTML_REPORT is set this shouldn't happen anymore.
- The `Add summaries` task is reporting errors but it's working regardless. I believe this might be due to -x being set instead of the original +x (I changed that by mistake).
Bump mono to get the new splited test dlls and add them to be ran in
xharness. Special logic is used for mscorlib so we make sure that all
the 'parts' of the test dll do have the same configurations.
Co-Authored-By: Waleed Chaudhry <54864665+wachaudh@users.noreply.github.com>
- Needed for the DDFun migration of our tests
- Don't use SSH because it's restricted on the new bots
- Use brand new DevOps feature to clone multiple repos via HTTPS
- Update names of all tasks (clearer)
- Simplify and re-use code
- Update all paths because our cloning strategy is different compared to old pipeline
- Update xharness to print "experimental" titles in GitHub comments
- Update xharness to not add the Html link for tests from the DDFun pipeline
- Fix all timeouts to be relevant to the tests length
- Split in multiple jobs (for GitHub status)
- Move longer scripts to independant files
- Make inline bash prettier
- Use a variable for the pool name
- Fix single space alignment
- Remove unused variable in `vsts-device-tests-set-status.sh` that broke it
- Bump maccore to use the right certificates and profiles
- Bump maccore to target the right pipeline
- Bump maccore to not use ssh in scripts
- Bump maccore and use persistCredentials
Notes:
- Right now the xharness test output can only be seen when downloading the zip file locally (better output soon)
- https://devdiv.visualstudio.com/DevDiv/_workitems/edit/947932
- It turns out the linker in some cases can wrap expected exceptions in a outer exception. By drilling in we can produce better errors, again.
- Refactor pipeline exception handling to be shared between mmp/mtouch
Copying the framework could fail (error 260) and the failure was never
reported so the build succeeded - but without updating (completely) the
framework.
The exact reason it fails is unknown :( but we can recover from it by
deleting the target and copying (everything) back to the expected
(target) location.
Build logs will now indicate when this fails and will try to recover
before reporting a build error. Best case it works :) worse case we'll
be aware something is wrong (which is better than ignoring)
This is half the fix from https://github.com/xamarin/xamarin-macios/pull/7544
which was reverted due to the second half causing a regression (under
investigation).
Reference: https://github.com/xamarin/xamarin-macios/issues/7514 (partial fix)
* [sample-tester] Collect app size and build duration statistics.
* Always publish performance data.
* [mmp] Add support for MMP_ENV_OPTIONS to mirror mtouch's MTOUCH_ENV_OPTIONS.
* [sample-tester] Make mmp/mtouch show timing information, and get the diagnostic msbuild log.
* Collect task and target info.
* Add more perf data and a baseline test.
* Redo the base test a bit.
* More tweaks.
* More tweaks.
* Huh?
* Debug stuff.
* diagnostics.
* Better diagnostics.
* cleanup
* tmp
* Use a separate stage to push data.
* Next attempt.
* Unique artifact names.
* Make the right name unique.
* More progress
* Improvements
* Don't need new maccore.
* cleanup
* Remove debug spew.
* Realign stuff.
* duh
* More path fixes.
* zippity zip.
* Show publishing errors.
* dependencies
* Not fake results anymore.
* Tweaks
* Merge xml files
* [sampletester] Bump nuget timeout to 5 minutes.
The TodoREST.iOS test seems to use a lot of packages, and it can apparently
take a while to restore them, so give a few more minutes.
* Improvements.
* Fix glob.
* [sampletester] Fix fetching of sample repository and hash.
* [sampletester] Centralize verbosity for mtouch and mmp.
Some of the test assemblies are too large and will be splitted by mono so
that they can be compiled for iOS 32b. In that case, we are using the
following pattern
`
test_assembly_name.dll
`
becomes
`
test_assembly_name.part1.dll
test_assembly_name.part2.dll
`
Perse the only change we need to add to make our life easier is to be
able to mantain a single .ignore file since mantaining more .ignore
files is hard and more error prone. This change simply checks if we are
working with a splitted dll and ensures that the correct .ignore files
are added to the BCL test application.
Co-Authored-By: Pramit Mallick <prmallic@microsoft.com>
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.
Updating the msbuild tasks to use netstandard2.0 requires us to bump NUnit to 3+.
This requires:
* A few code changes due to breaking API changes in NUnit.
* Changes in xharness and a makefile to cope with the new location for the
NUnit console runner (I added a helper script to make things slightly
easier).
It's possible for a nuget to have dependencies that will bring satellite
assemblies into a project.
When doing so the satellite assemblies are copied to the right output
(e.g. `Debug`) directory, so they work fine at runtime. However it's
not 100% fine at build time, e.g. msbuild won't detected them as
satellite assemblies.
Something similar happens with `mtouch` (and `mmp`) since the satellite
assemblies won't be found inside a (culture-named) subdirectory from the
original assembly location. In our case this means the assemblies won't
be copied into the .app bundle (since we don't run from `Debug`) and
localization won't work properly.
The solution is to check for both the (culture-named) subdirectories
from the assembly location (like before) and, if nothing is found, also
try to locate them in the _build_ (like `Debug`) directory - so if
something else (nuget or custom build scripts) tried to outsmart the
build logic then we'll still bring those satellite assemblies in the
app bundle we produce.
https://github.com/xamarin/xamarin-macios/issues/7113
The nice, repeatable test case from #7514 pointed out two issues
1. `cache.cs` ignored some changes
It looks like something changed (at some point) and the first _ignored_
line was the `@x.rsp` our response file - which should not be ignored.
This solved the build issue where updating the nuget should have
triggered a rebuild because
> /Users/poupou/.nuget/packages/skiasharp/1.68.0/lib/Xamarin.iOS/SkiaSharp.dll
and
> /Users/poupou/.nuget/packages/skiasharp/1.68.1/lib/Xamarin.iOS/SkiaSharp.dll
are different assemblies (but the same response file).
2. `copyfile` could fail silently
Copying the framework could fail (error 260) and the failure was never
reported so the build succeeded - but without updating (completely) the
framework.
The exact reason it fails is unknown :( but we can recover from it by
deleting the target and copying (everything) back to the expected
(target) location.
Build logs will now indicate when this fails and will try to recover
before reporting a build error. Best case it works :) worse case we'll
be aware something is wrong (which is better than ignoring)
ref: https://github.com/xamarin/xamarin-macios/issues/7514
* Do not call `Marshal.GetLastWin32Error` instead the callback
as the `SetLastError` logic has yet to be executed so we get a bogus
`260` value...
Instead we call it after the `copyfile` call returns but, at this stage,
the callback (i.e. **us**) signaled an error so what we get back (`17`)
is not very helpful - as we aborted (Quit) the logic when copying a file
that existed.
```c
#define EEXIST 17 /* File exists */
```
from Console logs
```
default 14:23:54.771292-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework: File exists
default 14:23:54.771620-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature: File exists
default 14:23:54.771850-0500 mono64 open on /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature/CodeResources: File exists
```
`copyfile.c` source code (might not be the latest) can be seen from
https://opensource.apple.com/source/copyfile/copyfile-42/copyfile.c
```c
if (mkdir(s->dst, mode) == -1) {
if (errno != EEXIST || (s->flags & COPYFILE_EXCL)) {
copyfile_warn("Cannot make directory %s", s->dst);
```
so `mkdir` fails - but not because of `EEXIST` and from `copyfile.h`
we see that `EXCL` exists but it's not using (or even defined) in our
bindings.
```c
#define COPYFILE_EXCL (1<<17) /* fail if destination exists */
```
So sadly the `Err` condition (inside the callback) does not give us more
detail about the error itself.
## Miscellaneous fixes
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
## Bring HttpClient from CoreFX
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
### SocketsHttpHandler
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
### Certificate Validation Changes
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
### Minor adjustments related to internal Mono APIs
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
### Minor adjustments to tests.
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
Keep 'CallContextSecurityData' around since it's quite small (and the
normal linker logic will be able to deal with it if unused) and allows
the use of `Thread.CurrentPrincipal`
Also add unit test.
Fix https://github.com/xamarin/xamarin-macios/issues/7321
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
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.
* [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
* [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