This should speed up getting bots ready, since now we only run the
provisionator once for each bot, and we also don't try to provision the
same thing multiple times.
Context: https://github.com/CommunityToolkit/Maui.NativeLibraryInterop
Introduces a `@(XcodeProject)` build action which can be used to build
and consume the outputs of Xcode framework projects.
The following metadata are supported on this item:
```xml
<XcodeProject Include="path/to/myproject.xcodeproj" >
<Configuration>Release</Configuration>
<CreateNativeReference>true</CreateNativeReference>
<ForceLoad></ForceLoad>
<Frameworks></Frameworks>
<Kind>Framework</Kind>
<OutputPath></OutputPath>
<SchemeName></SchemeName>
<SmartLink></SmartLink>
<Visible></Visible>
</XcodeProject>
```
* `%(SchemeName)`: The name of the build scheme or target that should
be used to build the project.
* `%(Configuration)`: The name of the configuration to use to build the
project. The default value is `Release`.
* `%(CreateNativeReference)`: Output XCFRAMEWORK files will be added as
a `@(NativeReference)` to the project. Metadata supported by
`@(NativeReference)` like `%(Kind)`, `%(Frameworks)`, or `%(SmartLink)`
will be forwarded if set. The default value is `true`.
* `%(OutputPath)`: Can be set to override the XCARCHIVE and XCFRAMEWORK
output path of the Xcode project. The default value is
`$(IntermediateOutputPath)xcode/{SchemeName}-{Hash}`.
A new `_BuildXcodeProjects` target will attempt to build XCARCHIVE and
XCFRAMEWORK files for each `@(XcodeProject)` item. These outputs will be
created for the platform specified in the target framework. If multiple
target frameworks are specified, the project will be built for each
platform during each inner build.
A new `$(MaciOSPrepareForBuildDependsOn)` build extension point has been
added to allow customer projects to more easily hook into the beginning
of the build process.
---------
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
Detect if we're using a non-stable Xcode, and in that case produce packages
that show an error if they're used and the EnablePreviewFeatures flag isn't
enabled.
Also add logic to set this flag for our own build, otherwise all our tests
would fail.
This is the same as Android does.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18343.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
* The manifest is gone, now we create an on the fly "manifest" using the "vsts-devdiv artifacts" json file
* Points VSMac to the selected Xcode path
* Switch to templated Xcode provisioning
* Turn Xcode symlinks into actual Xcode installations
Since 'packages' is a common dir name that is ignored. Revert the change
in the .gitignore and rename the template path since it just means a one
liner change in the entry yaml file.
fixes: https://github.com/xamarin/maccore/issues/2359
* [src] Build the .NET version of our product assemblies using a .NET 5 BCL.
We're not shipping the .NET product assemblies in any stable release, so we
can use a preview version of the .NET 5 BCL.
Also:
* Add all the nuget feeds we need to the top-level NuGet.config, even for .NET
5/6, there shouldn't be any conflicts with stable feeds since we use exact
version numbers.
* Generate a top-level global5.json which is copied to every directory that
needs a .NET 5 global.json (overriding the .NET 3.1 global.json in the root
directory).
* Use the expected dotnet binary during our local build.
* [tests] Fix the bgen tests to use .NET 5.
* [xharness] Set the current directory to the project directory when running .NET tests.
This way we end up using the dotnet version that's configured in global.json for the tests.
Move to use the provisionator and add a make file to generat the script
so that we only have to bump xcode in a single place.
Move all deps to provisionator and make provisionator download and
install the xi pkg that has been built to be tested in the pipeline, we
do not longer use curl to do it.
* [configure] Add --[enable|disable]-dotnet.
And make it enabled by default on CI and disabled by default elsewhere for now
(because it makes the build significantly slower).
* [system-dependencies] Add support for provisioning .NET.
Also write a global.json in the root directory which is how we select which
.NET version to use.
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>
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.
Add a separate provisioning script to install Xcode if it's not already installed on the bot.
For some unknown reason it needs to be a separate script, otherwise the provisionator will complain it doesn't know the required GitHub token to download Xcode.
Fixes https://github.com/xamarin/xamarin-macios/issues/6326.
Mono know provides a set of testing assemblies that contain the tests to be ran in each of the supported platforms. This commit adds the following:
1. Two different runners that can be used to execute NUnit and xUnit tests.
2. The necessary glue to get xharness to run the new tests and report the results.
3. A new test that will ensure that if mono adds new tests, xharness will report failures if the tests are not run or not ignored.
Those tests needs to be run with the linker disabled since they use
reflection for most of their work.
The original dontlink (for linker tests) was becoming too large in
some configuration (e.g. tvOS release with bitcode) but this was
due to other BCL assemblies (not the introspection tests)
Rolf Bjarne Kvinge
Peter Collins
Alex Soto
Manuel de la Pena
Vincent Dondain
Marek Safar
Sebastien Pouliot