* [xharness] Mark the .NET tests project as a .NET project so that we don't try to call nuget restore on it.
* [xharness] Mark the .NET generator project as a .NET project as well.
The filename arguments to the error logging must be strings, otherwise the
wrong logging overload is picked, and the resulting error message makes no
sense.
It's somewhat of a breaking change, since previously Xamarin.Mac would default
to 'false' if no value was set. It should be exceedingly rare though, since
it's set in all the template projects.
It makes the behavior a bit more intuitive for .NET projects, since then the
values might not be set because of the simplified project files.
* [DevOps] Report the correct bot used.
The tests are not executed in the same agent that sets the github
status, for that reason, the github comment is not giving the correct
bot name, but the name of the bot that executed the commit message and
not the tests.
Add an output var in the runTests step to set the bot name and pass it
to the comment job in a different bot.
* Update tools/devops/device-tests/scripts/GitHub.psm1
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
Packages are listed in the csproj when we're using package references.
Also only list files in git, otherwise we pick up all the generated project files as well.
Depending on the pipeline run, we should have the following result:
* failed: issues with bots or provisioning (red in the UI)
* partiallySucceeded: no issues with bots but failing tests.
* succeeded: no issues with bots and all tests pass.
This adds a psh cmdlet that allows to set the result AND sets the
correct result when we have test failures.
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
We're starting to use NuGet (packages) more and more, and NuGet stores
information about any package references in the bin/obj directories. This
means that if a directory has multiple project files, NuGet will get quite
confused because it will use the wrong package information half the time.
There are steps that can be taken to make NuGet write its package information
in different directories, but this becomes quite cumbersome to keep
up-to-date, and it's confusing when it breaks. It's much easier to just have a
blanket rule that there shouldn't be more than one project per directory.
However, it did require quite a few changes to xharness to fix assumptions
about where files are located.
Also clean the package directory before creating any packages, otherwise we
might end up trying to upload packages from the previous build.
Diff best viewed by ignoring whitespace.
* [dotnet] Only pass a single custom step to the linker.
The linker will load the assemblies with the custom steps once per custom step
argument, which means that each step is effectively in a different assembly,
making it impossible to share state between steps.
This behavior is filed as a linker bug: https://github.com/mono/linker/issues/1314
Until this is fixed, we can just have a single step that injects all the other
steps programmatically.
* [tests] Adjust .NET tests according to new behavior.
Fixes https://developercommunity.visualstudio.com/content/problem/934833/xamarinforms-cant-create-archive-for-ios.html
Depending on the default language of the running OS this could cause translating AM/PM to symbols that are not supported on folder names on Windows.
For instance, the value of `timestamp` without this change for an user that sets Chinese as it's main language would be `8-18-15 1.31 下午`, where `下午` represent PM.
Co-authored-by: emaf <ema@xamarin.com>
It turns out some Xamarin.Mac projects are library projects (for unit tests),
and we still need to generate makefile targets for those (because we use them
to build Xamarin.Mac tests to run on older macOS bots).