Move to use a template to perform the checkout. The new template allows
to perform the checkout using a resource alias, which later can be used
to use the template outside this repo.
Partial fix for https://github.com/xamarin/sdk-insertions/issues/41
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
In an attempt to unify the build of all the SDKs we need to be rename
all shared resources between the CIs to all use the same name.
This commit renames the resource to use the pattern used by MAUI.
Partial fix for https://github.com/xamarin/sdk-insertions/issues/39
Don't disable compact unwind info in the native linker, it may break C++
exception handling.
We originally disabled compact unwind info to fix a warning from the native
linker, this will have to be solved another way (in any case extra build
warnings is preferrable compared to an app crashing at runtime due to broken
C++ exception handling).
This partially reverts c05e774612.
Fixes https://github.com/xamarin/xamarin-macios/issues/16546.
The `%(Version)` metadata declared in `vs-workload.props` should always
be a four part version, this was missed when reviewing commit 9f1dc519ea.
Fix this by adding a trailing `.0` to stable branded packages.
For "Preview" branded manifest packs, the fourth part of the version
should be the commit distance (e.g. 16.1.0.5).
For "Stable" branded manifest packs, the third part of the version
should be the commit distance (e.g. 16.1.5.0).
See the following for more info on `vs-workload.props` versioning:
https://github.com/xamarin/sdk-insertions/wiki/How-to-create-a-new-insertion#msi-generation-and-vs-versioning-requirements
In an attempt to unify the build of all the SDKs we need to be rename all shared resources between the CIs to all use the same name.
This commit renames the resource to use the pattern used by MAUI.
Partial fix for xamarin/sdk-insertions#39
* Read the enabled platforms from the build configuration.
* Iterate over each platform, and only push the enabled ones to maestro.
* Iterate over each platform again, and only add the enabled ones to the default
channel (for the current branch).
* This makes it much easier to maintain the code, since it's possible to run it locally.
* Add tests!
* Add a DOTNET_PLATFORMS variable to the build configuration to list all the
enabled .NET platforms.
* Add INCLUDE_DOTNET_<platform> variables to the build configuration for each
enabled .NET platform. These new variables will be used in a future pull request.
The original change that caused a problem is not a problem anymore (it was
fixed in 18e2bef479), so re-introduce the
original change.
This reverts commit fb75cf80d2.
Update conversions from `NSDate` to `DateTime` and `DateTime` to `NSDate` to use date components instead of `SecondsSinceReferenceDate`.
The number of seconds since reference date is inconsistent between `NSDate` and `DateTime`. See the associated bug - converting `DateTime` 1/1/1 to `NSDate` ends up giving you an `NSDate` a couple days off :(
Fixes https://github.com/xamarin/xamarin-macios/issues/6993.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Update the download of API references to:
* Use `dl.internalx.com` links instead of `bosstoragemirror.blob.core.windows.net`
links (the relative path stays the same).
* Require a GitHub PAT in order to download from dl.internalx.com. This PAT
can either be provided through a file (recommended for local use) or through
the environment.
* Document these changes.
This introduces changes to ensure that the Github token is available at all provisionator invocations so that when we need to flip to using dl.internalx.com, there are no breakages.
Backport of #16511
Co-authored-by: cadsit <connor.adsit@gmail.com>
This introduces changes to ensure that the Github token is available at all provisionator invocations so that when we need to flip to using dl.internalx.com, there are no breakages.
Backport of #16511
Co-authored-by: cadsit <connor.adsit@gmail.com>
This introduces changes to ensure that the Github token is available at all provisionator invocations so that when we need to flip to using dl.internalx.com, there are no breakages.
Stable MSIs are versioned like non-stable MSIs, except that:
* We define the commit distance as the number of commits since the branch
bacame a release branch (and started using stable branding). Technically
this is the number of commits since the `NUGET_RELEASE_BRANCH` variable
changed (which will be incorrect for non-stable branches, but in that case
we shouldn't use this number in those scenarios).
* We use the above-mentioned commit distance as the third number in the MSI
version (as opposed to the fourth number in non-stable branches.)
Note: we detect if we're building a stable release by checking if the
`NUGET_PRERELEASE_IDENTIFIER` is empty (we can't use `NUGET_RELEASE_BRANCH`,
because this variable will be set for PRs to the release branch, while
`NUGET_PRERELEASE_IDENTIFIER` will only be empty for CI builds from a stable
branch).