Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
parameters :
- name : additionalBuildOptions
type : string
default : ''
- name : buildConfigurations
type : object
default :
- Release
- name : buildPlatforms
type : object
default :
- x64
- arm64
2025-05-14 12:15:19 -07:00
- name : official
type : boolean
default : false
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- name : codeSign
type : boolean
default : false
- name : artifactStem
type : string
default : ''
- name : jobName
type : string
default : 'Build'
- name : condition
type : string
default : ''
- name : dependsOn
type : object
default : [ ]
- name : pool
type : object
default : [ ]
- name : beforeBuildSteps
type : stepList
default : [ ]
- name : variables
type : object
default : {}
- name : publishArtifacts
type : boolean
default : true
- name : signingIdentity
type : object
default : {}
- name : enablePackageCaching
type : boolean
default : false
- name : enableMsBuildCaching
type : boolean
default : false
2025-09-24 01:28:39 -07:00
- name : msBuildCacheIsReadOnly
type : boolean
default : true
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- name : runTests
type : boolean
default : true
2025-06-17 17:56:48 +08:00
- name : buildTests
type : boolean
default : true
2024-11-13 12:36:45 -05:00
- name : useVSPreview
type : boolean
default : false
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- name : versionNumber
type : string
default : '0.0.1'
2024-12-19 09:00:53 +08:00
- name : useLatestWinAppSDK
type : boolean
default : false
- name : winAppSDKVersionNumber
type : string
default : 1.6
- name : useExperimentalVersion
type : boolean
default : false
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- name : csProjectsToPublish
type : object
default :
- 'src/settings-ui/Settings.UI/PowerToys.Settings.csproj'
- 'src/modules/launcher/PowerLauncher/PowerLauncher.csproj'
- 'src/modules/previewpane/MonacoPreviewHandler/MonacoPreviewHandler.csproj'
- 'src/modules/previewpane/MarkdownPreviewHandler/MarkdownPreviewHandler.csproj'
- 'src/modules/previewpane/SvgPreviewHandler/SvgPreviewHandler.csproj'
- 'src/modules/previewpane/SvgThumbnailProvider/SvgThumbnailProvider.csproj'
- 'src/modules/FileLocksmith/FileLocksmithUI/FileLocksmithUI.csproj'
[pipeline] Reduce CI, Fuzz, and UI Test Timeout from 4 Hours to 90 Minutes (#40500)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
The previous timeout for CI, fuzzing, and UI test builds was set to 4
hours, which often caused long wait times even when a job was already
stuck or failing.
To improve development feedback loops and reduce wasted time, the
timeout has been shortened to 90 minutes, which should still be
sufficient for normal runs but helps catch issues earlier.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2025-07-11 11:23:58 +08:00
- name : timeoutInMinutes
type : number
default : 240
- name : cancelTimeoutInMinutes
type : number
default : 1
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
jobs :
- job : ${{ parameters.jobName }}
${{ if ne(length(parameters.pool), 0) }}:
pool : ${{ parameters.pool }}
dependsOn : ${{ parameters.dependsOn }}
condition : ${{ parameters.condition }}
strategy :
matrix :
${{ each config in parameters.buildConfigurations }}:
${{ each platform in parameters.buildPlatforms }}:
${{ config }}_${{ platform }}:
BuildConfiguration : ${{ config }}
BuildPlatform : ${{ platform }}
${{ if eq(platform, 'x86') }}:
OutputBuildPlatform : Win32
${{ elseif eq(platform, 'Any CPU') }}:
OutputBuildPlatform : AnyCPU
${{ else }}:
OutputBuildPlatform : ${{ platform }}
variables :
2025-06-18 01:34:26 -07:00
MakeAppxPath : 'C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x86\MakeAppx.exe'
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
# Azure DevOps abhors a vacuum
# If these are blank, expansion will fail later on... which will result in direct substitution of the variable *names*
# later on. We'll just... set them to a single space and if we need to, check IsNullOrWhiteSpace.
# Yup.
MSBuildCacheParameters : ' '
JobOutputDirectory : $(Build.ArtifactStagingDirectory)
LogOutputDirectory : $(Build.ArtifactStagingDirectory)\logs
JobOutputArtifactName : build-$(BuildPlatform)-$(BuildConfiguration)${{ parameters.artifactStem }}
NUGET_RESTORE_MSBUILD_ARGS : /p:Platform=$(BuildPlatform) # Required for nuget to work due to self contained
NODE_OPTIONS : --max_old_space_size=16384
2025-06-17 17:56:48 +08:00
${{ if or(eq(parameters.runTests, true), eq(parameters.buildTests, true)) }}:
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
MSBuildMainBuildTargets : Build;Test
${{ else }}:
MSBuildMainBuildTargets : Build
${{ insert }}: ${{ parameters.variables }}
2024-12-19 09:00:53 +08:00
${{ if eq(parameters.useLatestWinAppSDK, true) }}:
RestoreAdditionalProjectSourcesArg : '/p:RestoreAdditionalProjectSources="$(Build.SourcesDirectory)\localpackages\NugetPackages"'
${{ else }}:
RestoreAdditionalProjectSourcesArg : ''
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
displayName : Build
[pipeline] Reduce CI, Fuzz, and UI Test Timeout from 4 Hours to 90 Minutes (#40500)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
The previous timeout for CI, fuzzing, and UI test builds was set to 4
hours, which often caused long wait times even when a job was already
stuck or failing.
To improve development feedback loops and reduce wasted time, the
timeout has been shortened to 90 minutes, which should still be
sufficient for normal runs but helps catch issues earlier.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2025-07-11 11:23:58 +08:00
timeoutInMinutes : ${{ parameters.timeoutInMinutes }}
cancelTimeoutInMinutes : ${{ parameters.cancelTimeoutInMinutes }}
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
templateContext : # Required when this template is hosted in 1ES PT
outputs :
- output : pipelineArtifact
artifactName : $(JobOutputArtifactName)
targetPath : $(Build.ArtifactStagingDirectory)
steps :
- checkout : self
clean : true
submodules : true
persistCredentials : True
fetchTags : false
fetchDepth : 1
- ${{ if eq(parameters.enableMsBuildCaching, true) }}:
- pwsh : |-
$MSBuildCacheParameters = ""
$MSBuildCacheParameters += " -graph"
$MSBuildCacheParameters += " -reportfileaccesses"
$MSBuildCacheParameters += " -p:MSBuildCacheEnabled=true"
$MSBuildCacheParameters += " -p:MSBuildCacheLogDirectory=$(LogOutputDirectory)\MSBuildCacheLogs"
2025-09-24 01:28:39 -07:00
# Cache read-only policy controlled by parameter
$cacheIsReadOnly = "${{ parameters.msBuildCacheIsReadOnly }}"
if ($cacheIsReadOnly -eq "True") {
$MSBuildCacheParameters += " /p:MSBuildCacheRemoteCacheIsReadOnly=true"
}
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
Write-Host "MSBuildCacheParameters: $MSBuildCacheParameters"
Write-Host "##vso[task.setvariable variable=MSBuildCacheParameters]$MSBuildCacheParameters"
displayName : Prepare MSBuildCache variables
2025-03-19 18:33:36 +00:00
- template : steps-ensure-dotnet-version.yml
parameters :
sdk : true
version : '6.0' # .NET 6.0 is required in CI for ESRP code signing tasks. Please do not remove.
2024-12-19 08:31:10 +08:00
- template : steps-ensure-dotnet-version.yml
parameters :
sdk : true
version : '8.0'
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- template : steps-ensure-dotnet-version.yml
parameters :
sdk : true
2024-11-13 12:36:45 -05:00
version : '9.0'
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- ${{ if eq(parameters.runTests, true) }}:
- task : VisualStudioTestPlatformInstaller@1
displayName : Ensure VSTest Platform
- pwsh : |-
& '.pipelines/applyXamlStyling.ps1' -Passive
2024-10-23 08:52:47 +01:00
displayName : Verify XAML formatting
- pwsh : |-
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
& '.pipelines/verifyNugetPackages.ps1' -solution '$(build.sourcesdirectory)\PowerToys.sln'
2024-10-23 08:52:47 +01:00
displayName : Verify Nuget package versions for PowerToys.sln
- pwsh : |-
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
& '.pipelines/verifyArm64Configuration.ps1' -solution '$(build.sourcesdirectory)\PowerToys.sln'
& '.pipelines/verifyArm64Configuration.ps1' -solution '$(build.sourcesdirectory)\tools\BugReportTool\BugReportTool.sln'
& '.pipelines/verifyArm64Configuration.ps1' -solution '$(build.sourcesdirectory)\tools\StylesReportTool\StylesReportTool.sln'
& '.pipelines/verifyArm64Configuration.ps1' -solution '$(build.sourcesdirectory)\installer\PowerToysSetup.sln'
2024-10-23 08:52:47 +01:00
displayName : Verify ARM64 configurations
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- ${{ if eq(parameters.enablePackageCaching, true) }}:
- task : Cache@2
displayName : 'Cache nuget packages (PackageReference)'
inputs :
key : '"PackageReference" | "$(Agent.OS)" | Directory.Packages.props'
restoreKeys : |
"PackageReference" | "$(Agent.OS)"
"PackageReference"
path : $(NUGET_PACKAGES)
- task : Cache@2
displayName : 'Cache nuget packages (packages.config)'
inputs :
key : '"packages.config" | "$(Agent.OS)" | **/packages.config'
restoreKeys : |
"packages.config" | "$(Agent.OS)"
"packages.config"
path : packages
2024-12-19 09:00:53 +08:00
- ${{ if eq(parameters.useLatestWinAppSDK, true)}}:
- template : .\steps-update-winappsdk-and-restore-nuget.yml
parameters :
versionNumber : ${{ parameters.winAppSDKVersionNumber }}
useExperimentalVersion : ${{ parameters.useExperimentalVersion }}
- ${{ if eq(parameters.useLatestWinAppSDK, false)}}:
- template : .\steps-restore-nuget.yml
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
2025-01-30 11:40:19 +00:00
- pwsh : |-
& "$(build.sourcesdirectory)\.pipelines\verifyAndSetLatestVCToolsVersion.ps1"
displayName : Work around DD-1541167 (VCToolsVersion)
${{ if eq(parameters.useVSPreview, true) }}:
env :
VCWhereExtraVersionTarget : '-prerelease'
2025-05-14 12:15:19 -07:00
- ${{ if eq(parameters.official, true) }}:
- template : .\steps-setup-versioning.yml
parameters :
directory : $(build.sourcesdirectory)\src\modules\cmdpal
Remove WiX v3 infrastructure and migrate exclusively to WiX v5 (#41975)
## Summary:
This pull request refactors the installer build pipeline to simplify and
modernize the process, focusing exclusively on the WiX 5 (VNext)
installer and removing legacy WiX 3 support. It eliminates the use of
the `installerSuffix` parameter and related logic, removes the legacy
installer build steps and scripts, and updates documentation to reflect
the new architecture. The changes streamline the pipeline, reduce
complexity, and ensure only the latest installer is built and signed.
Pipeline and build system simplification:
* Removed the `installerSuffix` parameter and all related logic from
pipeline templates and YAML files, including file naming, build steps,
and hash calculation scripts.
* Removed legacy WiX 3 installer build steps and the associated script
`installWiX.ps1`, focusing exclusively on WiX 5 (VNext) installer
builds.
Installer signing and build process updates:
* Updated `.pipelines/ESRPSigning_installer.json` to remove signing
configuration for the legacy `PowerToysSetupCustomActions.dll`, ensuring
only the VNext DLL is signed.
Documentation updates:
* Updated `doc/devdocs/core/installer.md` to remove references to WiX 3,
clarify the installer architecture as WiX 5 only, and describe the new
build process.
## CheckList:
- [ ] Should Build successfully and produce installer for both per user
and per machine
- [ ] Should install without problem
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: vanzue <69313318+vanzue@users.noreply.github.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
2025-10-16 16:39:50 -07:00
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- ${{ parameters.beforeBuildSteps }}
- task : VSBuild@1
${{ if eq(parameters.runTests, true) }}:
displayName : Build and Test PowerToys main project
${{ else }}:
displayName : Build PowerToys main project
inputs :
solution : 'PowerToys.sln'
vsVersion : 17.0
msbuildArgs : >-
-restore -graph
/p:RestorePackagesConfig=true
/p:CIBuild=true
/bl:$(LogOutputDirectory)\build-0-main.binlog
${{ parameters.additionalBuildOptions }}
$(MSBuildCacheParameters)
/t:$(MSBuildMainBuildTargets)
2024-12-19 09:00:53 +08:00
$(RestoreAdditionalProjectSourcesArg)
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
platform : $(BuildPlatform)
configuration : $(BuildConfiguration)
msbuildArchitecture : x64
maximumCpuCount : true
${{ if eq(parameters.enableMsBuildCaching, true) }}:
env :
SYSTEM_ACCESSTOKEN : $(System.AccessToken)
Initial DSC v3 support for PowerToys (#41132)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Tasks checklist
- [X] Implement DSC infra in PowerToys
- [X] Implement Settings DSC resource
- [X] Implement Get, Set, Test, Export, Schema
- [X] Generate manifest (DSC resource JSON)
- [X] Added Unit Tests
- [x] Add `NJsonSchema` v11.4.0 to the stream
- [x] Package the manifest files so dsc.exe can discover them
- [x] Add `PowerToys.DSC.exe` to the PATH (maybe?)
- [x] Add `InstallLocation` in the registry key so `winget configue
export` can export the PowerToys DSC resources
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [X] Closes: #37276
- [X] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [X] **Tests:** Added/updated and all pass
- [X] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Added/updated
- [x] **New binaries:** Added on the required places
- [x] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [x] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [x] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [x] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [x] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: vanzue <vanzue@outlook.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: Leilei Zhang <leilzh@microsoft.com>
2025-09-28 00:12:51 -07:00
# Build PowerToys.DSC.exe for ARM64 (x64 uses existing binary from previous build)
- task : VSBuild@1
displayName : Build PowerToys.DSC.exe (x64 for generating manifests)
condition : ne(variables['BuildPlatform'], 'x64')
inputs :
solution : src/dsc/v3/PowerToys.DSC/PowerToys.DSC.csproj
msbuildArgs : /t:Build /m /restore
platform : x64
configuration : $(BuildConfiguration)
msbuildArchitecture : x64
maximumCpuCount : true
# Generate DSC manifests using PowerToys.DSC.exe
- pwsh : |-
& '.pipelines/generateDscManifests.ps1' -BuildPlatform '$(BuildPlatform)' -BuildConfiguration '$(BuildConfiguration)' -RepoRoot '$(Build.SourcesDirectory)'
displayName : Generate DSC manifests
Add the Command Palette module (#37908)
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
- task : CopyFiles@2
displayName : Stage SDK/build
inputs :
contents : |-
"**/cmdpal/extensionsdk/nuget/Microsoft.CommandPalette.Extensions.SDK.props"
"**/cmdpal/extensionsdk/nuget/Microsoft.CommandPalette.Extensions.SDK.targets"
flattenFolders : True
targetFolder : $(JobOutputDirectory)/sdk/build
- task : CopyFiles@2
displayName : Stage SDK/lib
inputs :
contents : |-
"**/Microsoft.CommandPalette.Extensions.Toolkit/$(BuildPlatform)/release/WinUI3Apps/CmdPal/Microsoft.CommandPalette.Extensions.Toolkit.dll"
"**/Microsoft.CommandPalette.Extensions.Toolkit/$(BuildPlatform)/release/WinUI3Apps/CmdPal/Microsoft.CommandPalette.Extensions.Toolkit.deps.json"
flattenFolders : True
targetFolder : $(JobOutputDirectory)/sdk/lib/net8.0-windows10.0.19041.0
- task : CopyFiles@2
displayName : Stage SDK/winmd
inputs :
contents : |-
"**/Microsoft.CommandPalette.Extensions/$(BuildPlatform)/release/Microsoft.CommandPalette.Extensions/Microsoft.CommandPalette.Extensions.winmd"
flattenFolders : True
targetFolder : $(JobOutputDirectory)/sdk/winmd
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- task : VSBuild@1
displayName : Build BugReportTool
inputs :
solution : '**/tools/BugReportTool/BugReportTool.sln'
vsVersion : 17.0
msbuildArgs : >-
-restore -graph
/p:RestorePackagesConfig=true
/p:CIBuild=true
/bl:$(LogOutputDirectory)\build-bug-report.binlog
${{ parameters.additionalBuildOptions }}
$(MSBuildCacheParameters)
2024-12-19 09:00:53 +08:00
$(RestoreAdditionalProjectSourcesArg)
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
platform : $(BuildPlatform)
configuration : $(BuildConfiguration)
msbuildArchitecture : x64
maximumCpuCount : true
${{ if eq(parameters.enableMsBuildCaching, true) }}:
env :
SYSTEM_ACCESSTOKEN : $(System.AccessToken)
- task : VSBuild@1
displayName : Build StylesReportTool
inputs :
solution : '**/tools/StylesReportTool/StylesReportTool.sln'
vsVersion : 17.0
msbuildArgs : >-
-restore -graph
/p:RestorePackagesConfig=true
/p:CIBuild=true
/bl:$(LogOutputDirectory)\build-styles-report.binlog
${{ parameters.additionalBuildOptions }}
$(MSBuildCacheParameters)
2024-12-19 09:00:53 +08:00
$(RestoreAdditionalProjectSourcesArg)
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
platform : $(BuildPlatform)
configuration : $(BuildConfiguration)
msbuildArchitecture : x64
maximumCpuCount : true
${{ if eq(parameters.enableMsBuildCaching, true) }}:
env :
SYSTEM_ACCESSTOKEN : $(System.AccessToken)
- ${{ each project in parameters.csProjectsToPublish }}:
- task : VSBuild@1
displayName : Publish ${{ project }} for Packaging
inputs :
solution : ${{ project }}
vsVersion : 17.0
msbuildArgs : >-
/target:Publish
/graph
/p:Configuration=$(BuildConfiguration);Platform=$(BuildPlatform);AppxBundle=Never
/p:VCRTForwarders-IncludeDebugCRT=false
/p:PowerToysRoot=$(Build.SourcesDirectory)
/p:PublishProfile=InstallationPublishProfile.pubxml
2025-06-18 01:34:26 -07:00
/p:TargetFramework=net9.0-windows10.0.26100.0
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
/bl:$(LogOutputDirectory)\publish-${{ join('_',split(project, '/')) }}.binlog
2024-12-19 09:00:53 +08:00
$(RestoreAdditionalProjectSourcesArg)
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
platform : $(BuildPlatform)
configuration : $(BuildConfiguration)
msbuildArchitecture : x64
maximumCpuCount : true
[ci][Arm64]Manually copy WebView2 core dll after publishing (#35711)
After we upgraded Windows App SDK to 1.6, Dev Files Preview on Peek has been broken on ARM64.
For .86, we've added WebView2 to Registry Preview in order to have Monaco Editor as the text editor, which is also broken on ARM64.
After a lengthy investigation, it seems we've found the core issue, PowerToys has been shipping with a x64 Microsoft.Web.WebView2.Core.dll in the ARM64 installer, which fails at runtime.
We seem to have hit a version of https://github.com/microsoft/WindowsAppSDK/issues/4826
When we build PowerToys in Dart for release, we publish some of the C# WinUI3Apps after building PowerToys and before signing / building the install. This means that the WindowsAppSDK build will recopy its WebView2 dependency, which for some reason is ARM64. On local builds of PowerToys, PowerRename, a C++ WinAppSDK application finished last, which copies the right dll and it's the reason we weren't being able to repro the issue on local builds of ARM64 PowerToys.
This PR solves the issue by including a short time hack in the CI to copy the right dll after publishing the C# WinUI3Apps when building for ARM64.
## Validation Steps Performed
Waiting for 4 concurrent builds of ARM64 from Dart to test whether the problem is solved.
2024-11-01 20:18:33 +00:00
### HACK: On ARM64 builds, building an app with Windows App SDK copies the x64 WebView2 dll instead of the ARM64 one. This task makes sure the right dll is used.
- task : CopyFiles@2
displayName : HACK Copy core WebView2 ARM64 dll to output directory
condition : eq(variables['BuildPlatform'],'arm64')
inputs :
Add the Command Palette module (#37908)
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
contents : packages/Microsoft.Web.WebView2.1.0.2903.40/runtimes/win-ARM64/native_uap/Microsoft.Web.WebView2.Core.dll
[ci][Arm64]Manually copy WebView2 core dll after publishing (#35711)
After we upgraded Windows App SDK to 1.6, Dev Files Preview on Peek has been broken on ARM64.
For .86, we've added WebView2 to Registry Preview in order to have Monaco Editor as the text editor, which is also broken on ARM64.
After a lengthy investigation, it seems we've found the core issue, PowerToys has been shipping with a x64 Microsoft.Web.WebView2.Core.dll in the ARM64 installer, which fails at runtime.
We seem to have hit a version of https://github.com/microsoft/WindowsAppSDK/issues/4826
When we build PowerToys in Dart for release, we publish some of the C# WinUI3Apps after building PowerToys and before signing / building the install. This means that the WindowsAppSDK build will recopy its WebView2 dependency, which for some reason is ARM64. On local builds of PowerToys, PowerRename, a C++ WinAppSDK application finished last, which copies the right dll and it's the reason we weren't being able to repro the issue on local builds of ARM64 PowerToys.
This PR solves the issue by including a short time hack in the CI to copy the right dll after publishing the C# WinUI3Apps when building for ARM64.
## Validation Steps Performed
Waiting for 4 concurrent builds of ARM64 from Dart to test whether the problem is solved.
2024-11-01 20:18:33 +00:00
targetFolder : $(Build.SourcesDirectory)/ARM64/Release/WinUI3Apps/
flattenFolders : True
OverWrite : True
2025-05-02 20:38:11 -07:00
# Check if all projects (located in src sub-folder) import common props
- pwsh : |-
& '.pipelines/verifyCommonProps.ps1' -sourceDir '$(build.sourcesdirectory)\src'
displayName : Audit shared common props for CSharp projects in src sub-folder
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
# Check if deps.json files don't reference different dll versions.
- pwsh : |-
& '.pipelines/verifyDepsJsonLibraryVersions.ps1' -targetDir '$(build.sourcesdirectory)\$(BuildPlatform)\$(BuildConfiguration)'
displayName : Audit deps.json files for all applications
# Check if asset files on the main application paths are playing nice and avoiding basic conflicts.
- pwsh : |-
& '.pipelines/verifyPossibleAssetConflicts.ps1' -targetDir '$(build.sourcesdirectory)\$(BuildPlatform)\$(BuildConfiguration)'
displayName : Audit base applications path asset conflicts
- pwsh : |-
& '.pipelines/verifyPossibleAssetConflicts.ps1' -targetDir '$(build.sourcesdirectory)\$(BuildPlatform)\$(BuildConfiguration)\WinUI3Apps'
displayName : Audit WinAppSDK applications path asset conflicts
2024-12-19 09:00:53 +08:00
# To streamline the pipeline and prevent errors, skip this step during compatibility tests with the latest WinAppSDK.
- ${{ if eq(parameters.useLatestWinAppSDK, false) }}:
- pwsh : |-
& '.pipelines/verifyNoticeMdAgainstNugetPackages.ps1' -path '$(build.sourcesdirectory)\'
displayName : Verify NOTICE.md and NuGet packages match
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- ${{ if eq(parameters.runTests, true) }}:
# Publish test results which ran in MSBuild
- task : PublishTestResults@2
displayName : 'Publish Test Results'
inputs :
testResultsFormat : VSTest
testResultsFiles : '**/*.trx'
condition : ne(variables['BuildPlatform'],'arm64')
# Native dlls
- task : VSTest@2
condition : ne(variables['BuildPlatform'],'arm64') # No arm64 agents to run the tests.
displayName : 'Native Tests'
inputs :
platform : '$(BuildPlatform)'
configuration : '$(BuildConfiguration)'
testSelector : 'testAssemblies'
testAssemblyVer2 : |
**\KeyboardManagerEngineTest.dll
**\KeyboardManagerEditorTest.dll
2025-06-13 08:59:25 -07:00
**\*UnitTest*.dll
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
!**\obj\**
2025-05-14 12:16:35 -07:00
- pwsh : |-
Upgrade WinAppSDK to 1.8 official release (#41723)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This pull request primarily updates project dependencies to newer
versions, especially for the Windows App SDK and related packages, and
improves the build pipeline's logic for selecting MSIX packages. These
changes ensure compatibility with the latest SDK features and provide
more robust package selection during builds.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Dependency and SDK upgrades:
* Upgraded `Microsoft.WindowsAppSDK` and related packages (Base,
Foundation, WinUI, Runtime, DWrite, InteractiveExperiences, Widgets, AI)
to version 1.8.x in all relevant project files, including
`Directory.Packages.props`, `.vcxproj`, `.csproj`, and `packages.config`
files. This also involved updating import paths and error checks for the
new package structure.
[[1]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L60-R61)
[[2]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL3-R9)
[[3]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL144-R156)
[[4]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL156-R181)
[[5]](diffhunk://#diff-d3a7d80ebbca915b42727633451e769ed2306b418ef3d82b3b04fd5f79560f17L7-R16)
[[6]](diffhunk://#diff-1a988d33c4d4db67a9c3316796dce4c068ccfbc40472b8c91a52e4b3208d98c3L12-R12)
[[7]](diffhunk://#diff-c287aa619c009edee184eefb9ecdb4e36dde33ae322725536c31f4a0566b382fL6-R14)
[[8]](diffhunk://#diff-c287aa619c009edee184eefb9ecdb4e36dde33ae322725536c31f4a0566b382fR209-R214)
* Updated `Microsoft.Web.WebView2` to version 1.0.3179.45 and
`Microsoft.Windows.SDK.BuildTools` to 10.0.26100.4948 in
`Directory.Packages.props`.
[[1]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L48-R48)
[[2]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L60-R61)
Build and packaging improvements:
* Enhanced the MSIX package selection logic in the build pipeline
(`job-build-project.yml`) to prioritize platform-specific packages
(x64/arm64) and provide clearer logging and error handling when no
packages are found.
* Modified `Microsoft.CmdPal.UI.csproj` to disable Appx bundling and set
a specific test directory for Appx packages during CI builds, improving
build output organization.
These updates help ensure the project stays current with the latest SDKs
and improves reliability and transparency in the build process.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Signed-off-by: Shawn Yuan <shuaiyuan@microsoft.com>
Co-authored-by: Leilei Zhang <leilzh@microsoft.com>
2025-09-19 15:45:48 +08:00
$Packages = Get-ChildItem -Recurse -Filter "Microsoft.CmdPal.UI_*.msix"
Write-Host "Found $($Packages.Count) CmdPal MSIX package(s):"
foreach ($pkg in $Packages) {
Write-Host " - $($pkg.FullName)"
}
if ($Packages.Count -gt 0) {
2025-09-24 18:54:29 +08:00
# Priority: Look for platform-specific MSIX (x64/arm64) first, then fall back to any
Upgrade WinAppSDK to 1.8 official release (#41723)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This pull request primarily updates project dependencies to newer
versions, especially for the Windows App SDK and related packages, and
improves the build pipeline's logic for selecting MSIX packages. These
changes ensure compatibility with the latest SDK features and provide
more robust package selection during builds.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Dependency and SDK upgrades:
* Upgraded `Microsoft.WindowsAppSDK` and related packages (Base,
Foundation, WinUI, Runtime, DWrite, InteractiveExperiences, Widgets, AI)
to version 1.8.x in all relevant project files, including
`Directory.Packages.props`, `.vcxproj`, `.csproj`, and `packages.config`
files. This also involved updating import paths and error checks for the
new package structure.
[[1]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L60-R61)
[[2]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL3-R9)
[[3]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL144-R156)
[[4]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL156-R181)
[[5]](diffhunk://#diff-d3a7d80ebbca915b42727633451e769ed2306b418ef3d82b3b04fd5f79560f17L7-R16)
[[6]](diffhunk://#diff-1a988d33c4d4db67a9c3316796dce4c068ccfbc40472b8c91a52e4b3208d98c3L12-R12)
[[7]](diffhunk://#diff-c287aa619c009edee184eefb9ecdb4e36dde33ae322725536c31f4a0566b382fL6-R14)
[[8]](diffhunk://#diff-c287aa619c009edee184eefb9ecdb4e36dde33ae322725536c31f4a0566b382fR209-R214)
* Updated `Microsoft.Web.WebView2` to version 1.0.3179.45 and
`Microsoft.Windows.SDK.BuildTools` to 10.0.26100.4948 in
`Directory.Packages.props`.
[[1]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L48-R48)
[[2]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156L60-R61)
Build and packaging improvements:
* Enhanced the MSIX package selection logic in the build pipeline
(`job-build-project.yml`) to prioritize platform-specific packages
(x64/arm64) and provide clearer logging and error handling when no
packages are found.
* Modified `Microsoft.CmdPal.UI.csproj` to disable Appx bundling and set
a specific test directory for Appx packages during CI builds, improving
build output organization.
These updates help ensure the project stays current with the latest SDKs
and improves reliability and transparency in the build process.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Signed-off-by: Shawn Yuan <shuaiyuan@microsoft.com>
Co-authored-by: Leilei Zhang <leilzh@microsoft.com>
2025-09-19 15:45:48 +08:00
$PlatformPackage = $Packages | Where-Object { $_.Name -match "Microsoft\.CmdPal\.UI_.*_(x64|arm64)\.msix$" } | Select-Object -First 1
if ($PlatformPackage) {
$Package = $PlatformPackage
Write-Host "Using platform-specific package: $($Package.FullName)"
} else {
$Package = $Packages | Select-Object -First 1
Write-Host "Using first available package: $($Package.FullName)"
}
$PackageFilename = $Package.FullName
Write-Host "##vso[task.setvariable variable=CmdPalPackagePath]${PackageFilename}"
} else {
Write-Warning "No CmdPal MSIX packages found!"
}
2025-05-14 12:16:35 -07:00
displayName : Locate the CmdPal MSIX
Add the Command Palette module (#37908)
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
2025-05-14 12:16:35 -07:00
- ${{ if eq(parameters.codeSign, true) }}:
Add the Command Palette module (#37908)
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
- pwsh : |-
& "$(MakeAppxPath)" unpack /p "$(CmdPalPackagePath)" /d "$(JobOutputDirectory)/CmdPalPackageContents"
displayName : Unpack the MSIX for signing
- template : steps-esrp-signing.yml
parameters :
displayName : Sign CmdPal MSIX content
signingIdentity : ${{ parameters.signingIdentity }}
inputs :
FolderPath : '$(JobOutputDirectory)/CmdPalPackageContents'
signType : batchSigning
batchSignPolicyFile : '$(build.sourcesdirectory)\.pipelines\ESRPSigning_cmdpal_msix_content.json'
ciPolicyFile : '$(build.sourcesdirectory)\.pipelines\CIPolicy.xml'
- pwsh : |-
$outDir = New-Item -Type Directory "$(JobOutputDirectory)/_appx" -ErrorAction:Ignore
$PackageFilename = Join-Path $outDir.FullName (Split-Path -Leaf "$(CmdPalPackagePath)")
& "$(MakeAppxPath)" pack /h SHA256 /o /p $PackageFilename /d "$(JobOutputDirectory)/CmdPalPackageContents"
Copy-Item -Force $PackageFilename "$(CmdPalPackagePath)"
2025-05-14 12:16:35 -07:00
Remove-Item -Force -Recurse "$(JobOutputDirectory)/CmdPalPackageContents" -ErrorAction:Ignore
Remove-Item -Force -Recurse "$(JobOutputDirectory)/_appx" -ErrorAction:Ignore
Add the Command Palette module (#37908)
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
displayName : Re-pack the new CmdPal package after signing
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- template : steps-esrp-signing.yml
parameters :
displayName : Sign Core PowerToys
signingIdentity : ${{ parameters.signingIdentity }}
inputs :
2025-01-16 15:17:34 +00:00
FolderPath : '$(BuildPlatform)/$(BuildConfiguration)'
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
signType : batchSigning
batchSignPolicyFile : '$(build.sourcesdirectory)\.pipelines\ESRPSigning_core.json'
ciPolicyFile : '$(build.sourcesdirectory)\.pipelines\CIPolicy.xml'
- template : steps-esrp-signing.yml
parameters :
displayName : Sign DSC files
signingIdentity : ${{ parameters.signingIdentity }}
inputs :
FolderPath : 'src/dsc/Microsoft.PowerToys.Configure'
signType : batchSigning
batchSignPolicyFile : '$(build.sourcesdirectory)\.pipelines\ESRPSigning_DSC.json'
ciPolicyFile : '$(build.sourcesdirectory)\.pipelines\CIPolicy.xml'
2025-05-14 12:16:35 -07:00
- pwsh : |-
Copy-Item -Verbose -Force "$(CmdPalPackagePath)" "$(JobOutputDirectory)"
displayName : Stage the final CmdPal package
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
- template : steps-build-installer-vnext.yml
parameters :
codeSign : ${{ parameters.codeSign }}
signingIdentity : ${{ parameters.signingIdentity }}
versionNumber : ${{ parameters.versionNumber }}
additionalBuildOptions : ${{ parameters.additionalBuildOptions }}
- template : steps-build-installer-vnext.yml
parameters :
codeSign : ${{ parameters.codeSign }}
signingIdentity : ${{ parameters.signingIdentity }}
versionNumber : ${{ parameters.versionNumber }}
additionalBuildOptions : ${{ parameters.additionalBuildOptions }}
buildUserInstaller: true # NOTE : This is the distinction between the above and below rules
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
# This saves ~1GiB per architecture. We won't need these later.
# Removes:
Updates for check-spelling v0.0.25 (#40386)
## Summary of the Pull Request
- #39572 updated check-spelling but ignored:
> 🐣 Breaking Changes
[Code Scanning action requires a Code Scanning
Ruleset](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset)
If you use SARIF reporting, then instead of the workflow yielding an ❌
when it fails, it will rely on [github-advanced-security
🤖](https://github.com/apps/github-advanced-security) to report the
failure. You will need to adjust your checks for PRs.
This means that check-spelling hasn't been properly doing its job 😦.
I'm sorry, I should have pushed a thing to this repo earlier,...
Anyway, as with most refreshes, this comes with a number of fixes, some
are fixes for typos that snuck in before the 0.0.25 upgrade, some are
for things that snuck in after, some are based on new rules in
spell-check-this, and some are hand written patterns based on running
through this repository a few times.
About the 🐣 **breaking change**: someone needs to create a ruleset for
this repository (see [Code Scanning action requires a Code Scanning
Ruleset: Sample ruleset
](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset#sample-ruleset)).
The alternative to adding a ruleset is to change the condition to not
use sarif for this repository. In general, I think the github
integration from sarif is prettier/more helpful, so I think that it's
the better choice.
You can see an example of it working in:
- https://github.com/check-spelling-sandbox/PowerToys/pull/23
---------
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
2025-07-08 18:16:52 -04:00
# - All .pdb files from any static libs .libs (which were only used during linking)
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- pwsh : |-
$binDir = '$(Build.SourcesDirectory)'
$ImportLibs = Get-ChildItem $binDir -Recurse -File -Filter '*.exp' | ForEach-Object { $_.FullName -Replace "exp$","lib" }
$StaticLibs = Get-ChildItem $binDir -Recurse -File -Filter '*.lib' | Where-Object FullName -NotIn $ImportLibs
$Items = @()
$Items += Get-Item ($StaticLibs.FullName -Replace "lib$","pdb") -ErrorAction:Ignore
$Items | Remove-Item -Recurse -Force -Verbose -ErrorAction:Ignore
displayName : Clean up static libs PDBs
errorActionPreference : silentlyContinue # It's OK if this silently fails
- task : CopyFiles@2
displayName : Stage Installers
inputs :
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
contents : |-
**/PowerToys*Setup-*.exe
!**/PowerToysSetupVNext/obj/**
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
flattenFolders : True
targetFolder : $(JobOutputDirectory)
- task : CopyFiles@2
displayName : Stage Symbols
inputs :
contents : |-
**\*.pdb
!**\vc143.pdb
!**\*test*.pdb
flattenFolders : True
targetFolder : $(JobOutputDirectory)/symbols-$(BuildPlatform)/
- pwsh : |-
$p = "$(JobOutputDirectory)\"
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
Remove WiX v3 infrastructure and migrate exclusively to WiX v5 (#41975)
## Summary:
This pull request refactors the installer build pipeline to simplify and
modernize the process, focusing exclusively on the WiX 5 (VNext)
installer and removing legacy WiX 3 support. It eliminates the use of
the `installerSuffix` parameter and related logic, removes the legacy
installer build steps and scripts, and updates documentation to reflect
the new architecture. The changes streamline the pipeline, reduce
complexity, and ensure only the latest installer is built and signed.
Pipeline and build system simplification:
* Removed the `installerSuffix` parameter and all related logic from
pipeline templates and YAML files, including file naming, build steps,
and hash calculation scripts.
* Removed legacy WiX 3 installer build steps and the associated script
`installWiX.ps1`, focusing exclusively on WiX 5 (VNext) installer
builds.
Installer signing and build process updates:
* Updated `.pipelines/ESRPSigning_installer.json` to remove signing
configuration for the legacy `PowerToysSetupCustomActions.dll`, ensuring
only the VNext DLL is signed.
Documentation updates:
* Updated `doc/devdocs/core/installer.md` to remove references to WiX 3,
clarify the installer architecture as WiX 5 only, and describe the new
build process.
## CheckList:
- [ ] Should Build successfully and produce installer for both per user
and per machine
- [ ] Should install without problem
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: vanzue <69313318+vanzue@users.noreply.github.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
2025-10-16 16:39:50 -07:00
# Calculate hashes for installers
$userSetupFiles = Get-ChildItem -Path $p -Filter "PowerToysUserSetup*.exe"
$machineSetupFiles = Get-ChildItem -Path $p -Filter "PowerToysSetup*.exe" | Where-Object { $_.Name -notmatch "PowerToysUserSetup" }
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
if ($userSetupFiles.Count -gt 0) {
$userHash = ($userSetupFiles[0] | Get-FileHash).Hash;
$userPlat = "hash_user_$(BuildPlatform).txt";
$combinedUserPath = $p + $userPlat;
Remove WiX v3 infrastructure and migrate exclusively to WiX v5 (#41975)
## Summary:
This pull request refactors the installer build pipeline to simplify and
modernize the process, focusing exclusively on the WiX 5 (VNext)
installer and removing legacy WiX 3 support. It eliminates the use of
the `installerSuffix` parameter and related logic, removes the legacy
installer build steps and scripts, and updates documentation to reflect
the new architecture. The changes streamline the pipeline, reduce
complexity, and ensure only the latest installer is built and signed.
Pipeline and build system simplification:
* Removed the `installerSuffix` parameter and all related logic from
pipeline templates and YAML files, including file naming, build steps,
and hash calculation scripts.
* Removed legacy WiX 3 installer build steps and the associated script
`installWiX.ps1`, focusing exclusively on WiX 5 (VNext) installer
builds.
Installer signing and build process updates:
* Updated `.pipelines/ESRPSigning_installer.json` to remove signing
configuration for the legacy `PowerToysSetupCustomActions.dll`, ensuring
only the VNext DLL is signed.
Documentation updates:
* Updated `doc/devdocs/core/installer.md` to remove references to WiX 3,
clarify the installer architecture as WiX 5 only, and describe the new
build process.
## CheckList:
- [ ] Should Build successfully and produce installer for both per user
and per machine
- [ ] Should install without problem
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: vanzue <69313318+vanzue@users.noreply.github.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
2025-10-16 16:39:50 -07:00
echo "User: $userHash"
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
$userHash | out-file -filepath $combinedUserPath
}
if ($machineSetupFiles.Count -gt 0) {
$machineHash = ($machineSetupFiles[0] | Get-FileHash).Hash;
$machinePlat = "hash_machine_$(BuildPlatform).txt";
$combinedMachinePath = $p + $machinePlat;
Remove WiX v3 infrastructure and migrate exclusively to WiX v5 (#41975)
## Summary:
This pull request refactors the installer build pipeline to simplify and
modernize the process, focusing exclusively on the WiX 5 (VNext)
installer and removing legacy WiX 3 support. It eliminates the use of
the `installerSuffix` parameter and related logic, removes the legacy
installer build steps and scripts, and updates documentation to reflect
the new architecture. The changes streamline the pipeline, reduce
complexity, and ensure only the latest installer is built and signed.
Pipeline and build system simplification:
* Removed the `installerSuffix` parameter and all related logic from
pipeline templates and YAML files, including file naming, build steps,
and hash calculation scripts.
* Removed legacy WiX 3 installer build steps and the associated script
`installWiX.ps1`, focusing exclusively on WiX 5 (VNext) installer
builds.
Installer signing and build process updates:
* Updated `.pipelines/ESRPSigning_installer.json` to remove signing
configuration for the legacy `PowerToysSetupCustomActions.dll`, ensuring
only the VNext DLL is signed.
Documentation updates:
* Updated `doc/devdocs/core/installer.md` to remove references to WiX 3,
clarify the installer architecture as WiX 5 only, and describe the new
build process.
## CheckList:
- [ ] Should Build successfully and produce installer for both per user
and per machine
- [ ] Should install without problem
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: vanzue <69313318+vanzue@users.noreply.github.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
2025-10-16 16:39:50 -07:00
echo "Machine: $machineHash"
[Installer] Upgrade the installer from WiX3 to WiX5 (#40877)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Background: The current PowerToys installer is built using Wix3, which
has now been deprecated. To improve security, service quality, and
community support, we’re upgrading the installer to Wix5.
Implementation:
Created Wix5-based projects(PowerToysSetupVext and
PowerToysSetupCustomActionsVNext) within the installer while retaining
the existing Wix3 project. Both versions are built to generate separate
installation packages. The Wix3-related code will be removed after
successful release testing confirms no issues.
Special case:
Wix5 has removed the property for 'ShowFilesInUse'. Now, whenever a file
is in use during installation, a FilesInUse pop-upwill automatically
appear asking for the next step. To ensure this doesn't interfere with
scenarios that require silent installation (e.g. Winget method), we’ve
handled it using the bafunction approach.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jerry Xu <n.xu@outlook.com>
Co-authored-by: Kai Tao <69313318+vanzue@users.noreply.github.com>
Co-authored-by: leileizhang <leilzh@microsoft.com>
Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com>
Co-authored-by: vanzue <vanzue@outlook.com>
2025-08-25 18:39:11 +08:00
$machineHash | out-file -filepath $combinedMachinePath
}
displayName : Calculate file hashes for all installers
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
# Publishing the GPO files
- pwsh : |-
New-Item "$(JobOutputDirectory)/gpo" -Type Directory
Copy-Item src\gpo\assets\* "$(JobOutputDirectory)/gpo" -Recurse
displayName : Stage GPO files
# Running the tests may result in future jobs consuming artifacts out of this build
2025-06-17 17:56:48 +08:00
- ${{ if or(eq(parameters.runTests, true), eq(parameters.buildTests, true)) }}:
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
- task : CopyFiles@2
displayName : Stage entire build output
inputs :
sourceFolder : '$(Build.SourcesDirectory)'
contents : '$(BuildPlatform)/$(BuildConfiguration)/**/*'
targetFolder : '$(JobOutputDirectory)\$(BuildPlatform)\$(BuildConfiguration)'
2025-02-19 09:17:15 +08:00
- ${{ if eq(parameters.publishArtifacts, true) }}:
- publish : $(JobOutputDirectory)
artifact : $(JobOutputArtifactName)
displayName : Publish all outputs
Rewrite the entire Azure DevOps build system (#34984)
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
2024-09-25 11:23:58 -05:00
condition : always()
