Added Ventura machines to macTestConfigurations within both the
build-ci-pipeline and the build-pr-pipelines.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The tramslations are meant to be done per week using the cron job. The
cron job does not use the main stage template, ergo we can simplify the
stage by removing the translations.
We have noticed that the azure upload steps fail when they are executed
in a on prem windows machine. The infra team does not know what this is
happening. To work around it we are taking the following stes:
- Move the upload to a hosted image, which does work.
- Donot download all artefacts, since hosted images only have a 10 gb
hdd. We download all but the not needed files using negative match
patterns.
In our localization process, the Loc team builds the translations (in
the not-user-readable .lcl files) and merges them into the
'Localization' branch from a 'Lego/...' branch. After this happens, our
'Get Localization Translations' github action takes that commits and
creates a PR into main with those changes. It is really important that
this github action works because we will later delete the 'Localization'
branch and create a new one from the 'main' branch so that the branches
stay in sync.
There worked fine, but there is now a 'isDeletePrSourceBranchSelected'
input to the OneLocBuild task that defaults to true that deletes the
'Lego/...' branch right after the commit to 'Localization' is made. Due
to this, the github action cannot bring the commit to 'main' because the
'Lego/...' branch no longer exists.
The hope is that setting this input to false will successfully not
delete the 'Lego/...' branch allowing the rest of the flow to be
uninterrupted.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Also add 'run-packaged-macos-tests' to the labels we care about.
This fixes an issue where the label combination
'skip-all-tests,run-packaged-macos-tests' would not run any tests.
I have been testing these changes inside the xamarin-macios-translations
pipeline.
The last run was green (found
[here](https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6984912&view=results)).
I had to use some placeholder code for the actual calls for the
OneLocBuild task that will communicate with the Loc Team but it reached
those points as expected!
This PR also rips out calls to the main-stage.yml template to only use
the stages necessary for the OneLocBuild run over the weekend!
I think these changes are set to see if the main branch can trigger the
OneLocBuild Task over the weekend build!
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
A lot of code in our repo uses the presence of the BUILD_REVISION environment
variable to determine whether we're running in CI or not, so just set the
variable globally once so that it's always set - that way we never forget to
set it.
Note that the exact value of the variable doesn't matter, only that it's set.
Also change one place in the yaml that was depending on the contents of the
BUILD_REVISION to use the Azure Devops variable BUILD_SOURCEVERSION instead
(like we do everywhere else in our yaml code).
Allow to add a dependency before our build. This is used in the unified
pipeline to try to download the binaries if it can rather than building
from scratch.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Azure pipelines has this terrible design in which the path of the
checkout is different depending if you checkout a single repo or
several.
In this case, we have no issues on macios because we do know we have not
been checkout with anyother repo in the upload step, that is not the
case when working on the unified pipeline. Rather than adding some
complicated logic, we are going to be checking out the yaml templates so
that we have the same working directory structure.
It's often desired to run the install-workloads.sh script locally, in order to
diagnose problems with it.
So improve it a bit by:
* Adding a few comments explaining things.
* Don't assume we're in the correct directory.
* Figure out BUILD_SOURCESDIRECTORY if it's not already set.
* Validate a bit and show more helpful errors.
Hopefully future me will be grateful!
The template can be run by a diff pipeline, that means that the project
and the commit wont point to xmarin/xamarin-macios. We use the URI to
calculate the org and the repo to be passed to the pwh objects.
Fixes https://github.com/xamarin/sdk-insertions/issues/43
This makes sure we're at the right maccore hash before adding provisioning
profile (in particular we want to be at the hash where the PR branch is at,
not the tip of main (which is the default)).
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 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.
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>
Manuel de la Pena
dustin-wojciechowski
Rolf Bjarne Kvinge
TJ Lambert
Alex Soto
VS MobileTools Engineering Service 2