Due to an unexpected decision on behalf of the Azure Artifacts folks,
the default view for a feed with upstream sources reports all packages,
even if they are not actually populated into the feed.
This results in (uncontrolled) 401 errors whenever a new package appears
upstream, because the feed tells our users and our build system that it
is available, but fails when the download actually begins because it is
not allowed to "write" the upstream version to the feed.
When we first transitioned to the `R1` network isolation
environment--which required us to _not_ contact
powershellgallery.com--we had to give up on the `AzureFileCopy` task.
Since then, the `AzurePowerShell` task has also become somewhat broken
while OneBranch fixed the issue that prevented us from using
`AzureFileCopy`.
In short, we now need to:
- Install the Azure PowerShell modules directly from our own feed (which
satisfies the network constraint)
- ... using `PSResourceGet` ...
- ... for Windows PowerShell 5.1 ...
- which is used by `AzureFileCopy` to later perform authentication.
This required removing connections during the build to `nuget.org` and
`powershellgallery.com`.
The NuGet Tool task was downloading nuget from `nuget.org`
unconditionally.
The `AzureFileCopy` task was downloading `Az.Accounts` from
`powershellgallery.com` unconditionally.
Both of these tasks have better options nowadays.
Tested and passed in OneBranch on 2025-04-01.
This is required for us to move off Entra ID Application identity.
(cherry picked from commit 2e7c3fa313)
This was approved in #16957, so I will merge with one signoff.
This pull request also removes the original release and nightly
pipelines, but it does not remove the release pipeline _template_.
I had to demote the Azure job from being a _deployment_ to being a plain
old job, unfortunately. Alas! Review with whitespace disabled (or `git
diff -w`).
Unfortunately, the appLicensing restricted capability we used to make
Canary installable without the store only works on Windows 11. Because
of that, we have to restrict the app package to Windows 11 and above.
I'd rather not leave Windows 10 users out in the cold, so this pull
request also publishes Canary builds to the public storage bucket with
the name `Microsoft.WindowsTerminalCanary_latest_x64.zip` (etc.)
The version number will be kept inside the archive. It remains to be
seen whether that is a good idea!
When combined with #16048, Canary builds from Azure will automatically
run in portable mode!
After the nightly build completes, we'll automatically generate a
.appinstaller and publich it plus the msixbundle to an Azure Storage
account.
I had to add step/job customization to the publish step in the full
release pipeline template.
The .appinstaller hardcodes our XAML dependency, which makes it a bit of
a pain. We can revisit this later, and publish our dependencies
directly and automatically instead of hardcoding them.
I am considering moving the appinstaller generation step to the MSIX
bundling job, but this works right now and is not too terrible.
Closes#774
