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.
* [IntentsUI] Update bindings to Xcode 10 Beta 1
This commit also adds a strong dictionary version to
INPlayMediaIntentResponse.WeakNowPlayingInfo.
* Implement feedback
* [CoreMotion] Update bindings to Xcode 10 Beta 1
* Add a note about why sharpie did not pick up these classes
* Remove CMMovementDisorderManager from simulator checks since it is not available there
I obsoleted `GetProjectPoint` in favor of `Project` because of the introduction of `Unproject` (which made me realize the naming was wrong) and based on the API doc https://developer.apple.com/documentation/arkit/arcamera/2923538-projectpoint?language=objc.
The `CGPoint` returned is the projection of a point. An other naming option would have been `GetProjectedPoint` but I think `Project` is closer to the original and clear enough. You project/unproject something onto something else and you get the projection back.
Put the shell code for resetting README dependencies in a shell script instead
of embedded in the Makefile so that it's easier to write, read and debug.
Also add support for switching between different remotes for README
dependencies (this means that `make reset-X` will now work fine if `X`'s
remote changed).
A side effect is that all README dependencies will now end up with a 'xamarin'
remote in addition to the 'origin' remote, but this should have no other
effect.
The MSBuild tasks will codesign an executable if the executable's timestamp is
later than `_CodeSignature/CodeResources`'s timestamp (or if
`_CodeSignature/CodeResources` doesn't exist).
Unfortunately, the codesign executable modifies both of those files, and the
executable last. This means that even just after running codesign, the
executable's timestamp might be later than `_CodeSignature/CodeResources`'s
timestamp (due to HFS+'s one-second timestamp resolution, this might happen
all within the same second, which means that this is a random issue: the
problem only occurs if the executable was modified at least a second later
than `_CodeSignature/CodeResources`.)
So make sure to touch `_CodeSignature/CodeResources` after running codesign,
so that the next time a build occurs (with no modifications), we don't resign
needlessly.
Fixes this (random) test failure when running the MSBuild tests:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_NoModifications
#1: ../MySingleView/bin/iPhoneSimulator/Debug/MySingleView.app/MySingleView
Expected: 2017-11-30 10:04:20.000
But was: 2017-11-30 10:04:22.000
Fixes https://github.com/xamarin/maccore/issues/592.
Complete the earlier stubs (committed to avoid tests failures) and add
`[Mac (10,14, onlyOn64: true)]` attributes on them.
This solves two XM failures when running on Mojave
```
3) ApiCoreImageFiltersTest.CheckManagedFilters (Introspection.MacCoreImageFiltersTest.ApiCoreImageFiltersTest.CheckManagedFilters)
Managed filters not found for CIAreaMinMax, CIDither, CIGuidedFilter, CIMeshGenerator, CIMix, CISampleNearest
Expected: 0
But was: 6
at Introspection.ApiCoreImageFiltersTest.CheckManagedFilters () [0x0019e] in /Users/poupou/git/xcode10/xamarin-macios/tests/introspection/ApiCoreImageFiltersTest.cs:146
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
4) ApiCoreImageFiltersTest.CheckNativeFilters (Introspection.MacCoreImageFiltersTest.ApiCoreImageFiltersTest.CheckNativeFilters)
6 native filters missing: CIAreaMinMax, CIDither, CIGuidedFilter, CIMeshGenerator, CIMix, CISampleNearest
Expected: 0
But was: 6
```
Also introduce a new base type `CIReductionFilter` as found by tests
```
[WARN] CIAreaMaximum.SuperClass == CIReductionFilter (native) and CIFilter managed
[WARN] CIAreaMaximumAlpha.SuperClass == CIReductionFilter (native) and CIFilter managed
[WARN] CIAreaMinimum.SuperClass == CIReductionFilter (native) and CIFilter managed
[WARN] CIAreaMinimumAlpha.SuperClass == CIAreaMaximumAlpha (native) and CIFilter managed
```
Finally `CIMeshGenerator` is incomplete because the generator does not
support (never had to before) `NSArray` in filters, so we cannot express
`CIVector[]`. Filed as https://github.com/xamarin/xamarin-macios/issues/4226
* [Jenkins] Create artifacts.json and set a GH status as 'Jenkins: Artifacts'.
* [jenkins] Include the url in artifacts.json
* [jenkins] Add sha256 checksum to artifacts.json as well.
* [Jenkins] Enable xamarin before provisioning so that we auto-provision Xcode.
* [jenkins] Fix passing flags to configure.
Quoting empty CONFIGURE_FLAGS ends up doing this:
./configure "" --disable-ios-device
and since configure parses arguments until it finds an empty argument, it
would stop parsing at the first argument, effectively not disabling the device
build.
So don't quote CONFIGURE_FLAGS when invoking configure. shellcheck doesn't
quite like this, but the better code is much more complex, and not really
needed, so just add an exception.
Add support for building on internal Jenkins.
Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a `jenkins/Jenkinsfile`, which means it will start working as soon as this PR is merged.
Results will be posted as statuses on each commit, which can be viewed using the url `https://github.com/xamarin/xamarin-macios/commits/<branch>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* The `continuous-integration/jenkins/branch` status links to the jenkins job.
* The other two are XI and XM packages (the `Jenkins-` prefix will be removed once we officially switch from Wrench to Jenkins).
More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format `https://github.com/xamarin/xamarin-macios/commit/<sha1>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the `/commits/` url). Tip: it's possible to use `<sha1>` instead of `<branch>` (and vice versa for that matter) if you're interested in the statuses of a particular commit.
Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will **not** add a comment in the pull request in this case.
However, if the label `build-package` [1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2].
[1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but `run-on-internal-jenkins-and-create-package` is a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas:
* `run-internal-jenkins`: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins)
* We could have multiple labels that mean the same thing: `build-package`, `internal-build`, `run-internal-jenkins`, etc, but it's redundant and I don't quite like it either.
* Any other ideas?
[2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say **Build success/failure** and **Build comment file:** at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?
For the api diff for this PR we now show:
* `🔥 breaking changes 🔥`: If there are any breaking changes in the api diff (for this PR).
* `please review changes`: If there are any non-breaking changes in the api diff.
* `no change`: If the api diff is empty.
For the generator diff we show:
* `only version changes`: If there were only changes related to version numbers (since the XI/XM version number is added to the generator, that version number will always show up as a diff when comparing the generated source code)
* `please review changes`: If anything other that version numbers changed in the generated source code.
A few general categories of fixes:
* Sprinkle lots of quotes everywhere.
* Don't use environment variables in the format string to printf, instead pass them as arguments.
* Don't use backticks to execute commands (it's deprecated), use the new "$(...)" syntax instead.
Implement support for skipping API comparison by applying a label to a pull
request.
This also required some refactoring to move existing code to fetch the labels
for a pull request to a separate script.
We can't create an API/generator diff for a pull request with conflicts, so
detect this scenario and show a better error than this (from #3961):
Comparing the changes between origin/pr/3961/merge^1 and HEAD:
fatal: ambiguous argument 'origin/pr/3961/merge^1..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: ambiguous argument 'origin/pr/3961/merge^1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'