Mirrors/PowerToys
1
0
Fork 0
mirror of https://github.com/microsoft/PowerToys.git synced 2026-04-08 12:18:50 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
798564eea499409126c2373bfb79a4f1fdb9afad
PowerToys/.pipelines/v2/release.yml

156 lines
6.2 KiB
YAML
Raw Normal View History

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
trigger: none
pr: none
resources:
repositories:
- repository: 1ESPipelineTemplates
type: git
name: 1ESPipelineTemplates/1ESPipelineTemplates
ref: refs/tags/release
# Expose all of these parameters for user configuration.
parameters:
release: do not publish symbols to the public by default (#35070) This also moves the checkbox higher up so it is more prominent.
2024-09-25 13:15:18 -05:00
- name: publishSymbolsToPublic
displayName: "Publish Symbols to **PUBLIC** (use only for Final Builds)"
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
displayName: "Version Number"
type: string
default: '0.0.1'
- name: buildConfigurations
displayName: "Build Configurations"
type: object
default:
- Release
- name: buildPlatforms
displayName: "Build Platforms"
type: object
default:
- x64
- arm64
[Dev][Build] .NET 9 Upgrade (#35716) * [Deps] Upgrade Framework Libraries to .NET 9 RC2 * [Common][Build] Update TFM to NET9 * [FileLocksmith][Build] Update TFM to NET9 in Publish Profile * [PreviewPane][Build] Update TFM to NET9 in Publish Profile * [PTRun][Build] Update TFM to NET9 in Publish Profile * [Settings][Build] Update TFM to NET9 in Publish Profile * [MouseWithoutBorders][Analyzers] Resolve WFO1000 by configuring Designer Serialization Visibility * [Deps] Update Microsoft.CodeAnalysis.NetAnalyzers * [Analyzers] Set CA1859,CA2263,CA2022 to be excluded from error * [MouseWithoutBorders] Use System.Threading.Lock to lock instead of object instance * [ColorPicker] Use System.Threading.Lock to lock instead of object instance * [AdvancedPaste] Use System.Threading.Lock to lock instead of object instance * [TextExtractor] Use System.Threading.Lock to lock instead of object instance * [Hosts] Use System.Threading.Lock to lock instead of object instance * [MouseJump] Use System.Threading.Lock to lock instead of object instance * [PTRun] Use System.Threading.Lock to lock instead of object instance * [Wox] Use System.Threading.Lock to lock instead of object instance * [Peek] Use System.Threading.Lock to lock instead of object instance * [PowerAccent] Use System.Threading.Lock to lock instead of object instance * [Settings] Use System.Threading.Lock to lock instead of object instance * [Deps] Update NOTICE.md * [CI] Update .NET version step to target 9.0 * [Build] Attempt to add manual trigger for using Visual Studio Preview for building * [Build] Fix variable typo * [Build][Temporary] set to use preview builds * [Build] Add missing parameters * [Build][Temporary] directly hardcode preview image * [Build][Temporary] Trying ImageOverride * [Build] Revert hardcode and use ImageOverride * [Build] Add env var for adding prerelease argument for vswhere * [Build] Update VCToolsVersion script to use env var to optionally add prerelease version checking * [Build] Remove unneeded parameter * [Build] Re-add parameter in all the right places * [CI][Build] Add NoWarn NU5104 when building with VS Preview * [Deps] Update to stable .NET 9 packages * [Deps] Update NOTICE.md * Everything is WPF and WindowsForms now to fix .NET 9 dependency conflicts * Ensure .NET 9 SDK for tests too --------- Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
2024-11-13 12:36:45 -05:00
- name: useVSPreview
type: boolean
displayName: "Build Using Visual Studio Preview"
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: $(BuildDefinitionName)_$(date:yyMM).$(date:dd)$(rev:rrr)
cmdpal: use the unified Windows Terminal Versioning scheme (#39320) This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES". It only does so for the command palette. All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles. This will ensure that all artifacts that we produce are versioned properly: | thing | version (ex.) | |---------|-----------------| | dll/exe | 0.2.2505.08001 | | nupkg | 0.2.250508001 | | appx | 0.2.3269.0 | For reference, here's the version format: ### EXE, DLL, .NET Assembly 0.2.2505.08001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### NuGet Package 0.2.250508001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### AppX Package 0.2.01281.0 (the leading 0 will be removed) ^ ^ ^ ^^ ^ | | | || `-Contractually always zero (a waste) | | | |`-Build # on that date | | | `-Number of days in [base year] | | `-Number of years since [base year] | `-Minor `-Major [base year] = $(XesBaseYearForStoreVersion) It is expected that the base year is changed every time the version number is changed.
2025-05-14 12:15:19 -07:00
variables:
- template: templates/variables-nuget-package-version.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
extends:
template: v1/1ES.Official.PipelineTemplate.yml@1ESPipelineTemplates
parameters:
customBuildTags:
- 1ES.PT.ViaStartRight
pool:
name: SHINE-INT-S
[Dev][Build] .NET 9 Upgrade (#35716) * [Deps] Upgrade Framework Libraries to .NET 9 RC2 * [Common][Build] Update TFM to NET9 * [FileLocksmith][Build] Update TFM to NET9 in Publish Profile * [PreviewPane][Build] Update TFM to NET9 in Publish Profile * [PTRun][Build] Update TFM to NET9 in Publish Profile * [Settings][Build] Update TFM to NET9 in Publish Profile * [MouseWithoutBorders][Analyzers] Resolve WFO1000 by configuring Designer Serialization Visibility * [Deps] Update Microsoft.CodeAnalysis.NetAnalyzers * [Analyzers] Set CA1859,CA2263,CA2022 to be excluded from error * [MouseWithoutBorders] Use System.Threading.Lock to lock instead of object instance * [ColorPicker] Use System.Threading.Lock to lock instead of object instance * [AdvancedPaste] Use System.Threading.Lock to lock instead of object instance * [TextExtractor] Use System.Threading.Lock to lock instead of object instance * [Hosts] Use System.Threading.Lock to lock instead of object instance * [MouseJump] Use System.Threading.Lock to lock instead of object instance * [PTRun] Use System.Threading.Lock to lock instead of object instance * [Wox] Use System.Threading.Lock to lock instead of object instance * [Peek] Use System.Threading.Lock to lock instead of object instance * [PowerAccent] Use System.Threading.Lock to lock instead of object instance * [Settings] Use System.Threading.Lock to lock instead of object instance * [Deps] Update NOTICE.md * [CI] Update .NET version step to target 9.0 * [Build] Attempt to add manual trigger for using Visual Studio Preview for building * [Build] Fix variable typo * [Build][Temporary] set to use preview builds * [Build] Add missing parameters * [Build][Temporary] directly hardcode preview image * [Build][Temporary] Trying ImageOverride * [Build] Revert hardcode and use ImageOverride * [Build] Add env var for adding prerelease argument for vswhere * [Build] Update VCToolsVersion script to use env var to optionally add prerelease version checking * [Build] Remove unneeded parameter * [Build] Re-add parameter in all the right places * [CI][Build] Add NoWarn NU5104 when building with VS Preview * [Deps] Update to stable .NET 9 packages * [Deps] Update NOTICE.md * Everything is WPF and WindowsForms now to fix .NET 9 dependency conflicts * Ensure .NET 9 SDK for tests too --------- Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
2024-11-13 12:36:45 -05:00
${{ if eq(parameters.useVSPreview, true) }}:
[Dev][Build] VS 2026 Support (#44304) <!-- 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 PR updates the PowerToys solution to support **Visual Studio 2026 (PlatformToolset v145)**. It centralizes the build configuration, updates the C++ language standards, and fixes an issue with a MouseJump unit test that appears while using the VS 2026 supported build agent. <!-- 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 - [x] **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 **Build System & Configuration:** - Updated `Cpp.Build.props` to use `v145` (VS 2026) as the default `PlatformToolset`, with fall back to `v143` for VS 2022. - Configured C++ Language Standard: - `stdcpplatest` for production projects. - Removed explicit `<PlatformToolset>` definitions from individual project files (approx. 37 modules) to inherit correctly from the central `Cpp.Build.props`. **Code Refactoring & Fixes:** - Updated `DrawingHelperTests.cs` in MouseJump Unit Test to ease the pixel difference tolerance. This became an issue after switching to the new VS2026 build agent. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - Validated successful compilation of the entire solution. Similar updates have been made to the .NET 10 branch, but these are much cleaner and will be merged into that branch once fully confirmed working. --------- Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com> Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
2026-01-28 18:46:34 -05:00
demands: ImageOverride -equals SHINE-VS18-Preview
${{ else }}:
demands: ImageOverride -equals SHINE-VS18-Latest
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
os: windows
sdl:
tsa:
enabled: true
configFile: '$(Build.SourcesDirectory)\.pipelines\tsa.json'
build: remove *tests* and all coverage/DIA DLLs from binskim (#41108) This thing files about 900 bugs a month on us. Before: ``` Done. 11,036 files scanned. ``` After: ``` Done. 4,753 files scanned. ```
2025-08-18 06:00:13 -05:00
binskim:
enabled: true
# Exclude every dll/exe in tests/*, as well as all msdia*, covrun* and vcruntime*
analyzeTargetGlob: +:file|$(Build.ArtifactStagingDirectory)/**/*.dll;+:file|$(Build.ArtifactStagingDirectory)/**/*.exe;-:file:regex|tests.*\.(dll|exe)$;-:file:regex|(covrun.*)\.dll$;-:file:regex|(msdia.*)\.dll$;-:file:regex|(vcruntime.*)\.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
stages:
- stage: Build
displayName: Build
dependsOn: []
jobs:
- template: .pipelines/v2/templates/job-build-project.yml@self
parameters:
pool:
name: SHINE-INT-L
build: run all builds out of a new (huge) P:\ drive (#42739) The new agents have much smaller temporary disks (which I verified with another test run to clock in at about 87GB). For right now, let's move our release builds to a larger drive while we troubleshoot.
2025-10-21 18:32:34 -05:00
demands:
# Our INT agents have a large disk mounted at P:\
- ${{ if eq(parameters.useVSPreview, true) }}:
[Dev][Build] VS 2026 Support (#44304) <!-- 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 PR updates the PowerToys solution to support **Visual Studio 2026 (PlatformToolset v145)**. It centralizes the build configuration, updates the C++ language standards, and fixes an issue with a MouseJump unit test that appears while using the VS 2026 supported build agent. <!-- 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 - [x] **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 **Build System & Configuration:** - Updated `Cpp.Build.props` to use `v145` (VS 2026) as the default `PlatformToolset`, with fall back to `v143` for VS 2022. - Configured C++ Language Standard: - `stdcpplatest` for production projects. - Removed explicit `<PlatformToolset>` definitions from individual project files (approx. 37 modules) to inherit correctly from the central `Cpp.Build.props`. **Code Refactoring & Fixes:** - Updated `DrawingHelperTests.cs` in MouseJump Unit Test to ease the pixel difference tolerance. This became an issue after switching to the new VS2026 build agent. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - Validated successful compilation of the entire solution. Similar updates have been made to the .NET 10 branch, but these are much cleaner and will be merged into that branch once fully confirmed working. --------- Co-authored-by: Kai Tao (from Dev Box) <kaitao@microsoft.com> Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
2026-01-28 18:46:34 -05:00
- ImageOverride -equals SHINE-VS18-Latest-Preview
- ${{ else }}:
- ImageOverride -equals SHINE-VS18-Latest
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
os: windows
variables:
IsPipeline: 1 # The installer uses this to detect whether it should pick up localizations
SkipCppCodeAnalysis: 1 # Skip the code analysis to speed up release CI. It runs on PR CI, anyway
# IsExperimentationLive: 1 # The build and installer use this to turn on experimentation
buildPlatforms: ${{ parameters.buildPlatforms }}
buildConfigurations: ${{ parameters.buildConfigurations }}
versionNumber: ${{ parameters.versionNumber }}
publishArtifacts: false # 1ES PT handles publication for us.
cmdpal: use the unified Windows Terminal Versioning scheme (#39320) This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES". It only does so for the command palette. All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles. This will ensure that all artifacts that we produce are versioned properly: | thing | version (ex.) | |---------|-----------------| | dll/exe | 0.2.2505.08001 | | nupkg | 0.2.250508001 | | appx | 0.2.3269.0 | For reference, here's the version format: ### EXE, DLL, .NET Assembly 0.2.2505.08001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### NuGet Package 0.2.250508001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### AppX Package 0.2.01281.0 (the leading 0 will be removed) ^ ^ ^ ^^ ^ | | | || `-Contractually always zero (a waste) | | | |`-Build # on that date | | | `-Number of days in [base year] | | `-Number of years since [base year] | `-Minor `-Major [base year] = $(XesBaseYearForStoreVersion) It is expected that the base year is changed every time the version number is changed.
2025-05-14 12:15:19 -07:00
official: 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
codeSign: true
runTests: false
Build: Fix release pipeline and local build failure (#45211) ## Summary of the Pull Request Release pipeline is keeping failed, and local build failed at ut. This pull request introduces changes to improve how test projects are handled during release builds, ensuring that test code is not compiled or analyzed when not needed - in doing release build, to - succeed the execution and reduce built time. And, to upgrade from VS17 to VS18 in cmdpal sdk build, this is to keep consistency with all other build step <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **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 Local build & release pipeline build should all pass: Local build: <img width="1815" height="281" alt="image" src="https://github.com/user-attachments/assets/f350cf3f-b856-432d-97f3-e392d38ef7fa" /> Release pipeline is working too: <img width="1195" height="163" alt="image" src="https://github.com/user-attachments/assets/ce58de38-f0fb-45ad-9d70-2b8eb1c4db60" /> --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2026-02-02 09:15:53 +08:00
buildTests: 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
signingIdentity:
serviceName: $(SigningServiceName)
appId: $(SigningAppId)
tenantId: $(SigningTenantId)
akvName: $(SigningAKVName)
authCertName: $(SigningAuthCertName)
signCertName: $(SigningSignCertName)
build: add a couple more signing variables to ESRP (#37328) This is in support of some identity changes we need to make.
2025-02-06 12:35:25 -08:00
useManagedIdentity: $(SigningUseManagedIdentity)
clientId: $(SigningOriginalClientId)
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
# Have msbuild use the release nuget config profile
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
additionalBuildOptions: /p:RestoreConfigFile="$(Build.SourcesDirectory)\.pipelines\release-nuget.config" /p:EnableCmdPalAOT=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
beforeBuildSteps:
# Sets versions for all PowerToy created DLLs
- pwsh: |-
cmdpal: use the unified Windows Terminal Versioning scheme (#39320) This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES". It only does so for the command palette. All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles. This will ensure that all artifacts that we produce are versioned properly: | thing | version (ex.) | |---------|-----------------| | dll/exe | 0.2.2505.08001 | | nupkg | 0.2.250508001 | | appx | 0.2.3269.0 | For reference, here's the version format: ### EXE, DLL, .NET Assembly 0.2.2505.08001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### NuGet Package 0.2.250508001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### AppX Package 0.2.01281.0 (the leading 0 will be removed) ^ ^ ^ ^^ ^ | | | || `-Contractually always zero (a waste) | | | |`-Build # on that date | | | `-Number of days in [base year] | | `-Number of years since [base year] | `-Minor `-Major [base year] = $(XesBaseYearForStoreVersion) It is expected that the base year is changed every time the version number is changed.
2025-05-14 12:15:19 -07:00
.pipelines/versionSetting.ps1 -versionNumber '${{ parameters.versionNumber }}' -DevEnvironment ''
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: Prepare versioning
# Prepare the localizations and telemetry config before the release build
- template: .pipelines/v2/templates/steps-fetch-and-prepare-localizations.yml@self
release: stop hardcoding version numbers for the telemetry package (#39390)
2025-05-12 20:27:29 -05:00
- pwsh: |-
$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $true
& nuget.exe restore -configFile .pipelines/release-nuget.config -PackagesDirectory . .pipelines/packages.config
Move-Item -Force -Verbose "Microsoft.PowerToys.Telemetry.*\build\include\TraceLoggingDefines.h" "src\common\Telemetry\TraceLoggingDefines.h"
Move-Item -Force -Verbose "Microsoft.PowerToys.Telemetry.*\build\include\TelemetryBase.cs" "src\common\Telemetry\TelemetryBase.cs"
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: Emplace telemetry files
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>. ![cmdpal-pr-002](https://github.com/user-attachments/assets/5077ec04-1009-478a-92d6-0a30989d44ac) ![cmdpal-pr-003](https://github.com/user-attachments/assets/63b4762a-9c19-48eb-9242-18ea48240ba0) ---- 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
- stage: Build_SDK
displayName: Build SDK
dependsOn: []
jobs:
- template: .pipelines/v2/templates/job-build-sdk.yml@self
parameters:
pool:
name: SHINE-INT-L
os: windows
cmdpal: use the unified Windows Terminal Versioning scheme (#39320) This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES". It only does so for the command palette. All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles. This will ensure that all artifacts that we produce are versioned properly: | thing | version (ex.) | |---------|-----------------| | dll/exe | 0.2.2505.08001 | | nupkg | 0.2.250508001 | | appx | 0.2.3269.0 | For reference, here's the version format: ### EXE, DLL, .NET Assembly 0.2.2505.08001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### NuGet Package 0.2.250508001 ^ ^ ^ ^ ^ ^ | | | | | `-Build # on that date | | | | `-Day | | | `-Month | | `-Year | `-Minor `-Major ### AppX Package 0.2.01281.0 (the leading 0 will be removed) ^ ^ ^ ^^ ^ | | | || `-Contractually always zero (a waste) | | | |`-Build # on that date | | | `-Number of days in [base year] | | `-Number of years since [base year] | `-Minor `-Major [base year] = $(XesBaseYearForStoreVersion) It is expected that the base year is changed every time the version number is changed.
2025-05-14 12:15:19 -07:00
official: 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>. ![cmdpal-pr-002](https://github.com/user-attachments/assets/5077ec04-1009-478a-92d6-0a30989d44ac) ![cmdpal-pr-003](https://github.com/user-attachments/assets/63b4762a-9c19-48eb-9242-18ea48240ba0) ---- 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
codeSign: true
signingIdentity:
serviceName: $(SigningServiceName)
appId: $(SigningAppId)
tenantId: $(SigningTenantId)
akvName: $(SigningAKVName)
authCertName: $(SigningAuthCertName)
signCertName: $(SigningSignCertName)
useManagedIdentity: $(SigningUseManagedIdentity)
clientId: $(SigningOriginalClientId)
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
- stage: Publish
displayName: Publish
dependsOn: [Build]
jobs:
- template: .pipelines/v2/templates/job-publish-symbols-using-symbolrequestprod-api.yml@self
parameters:
versionNumber: ${{ parameters.versionNumber }}
includePublicSymbolServer: ${{ parameters.publishSymbolsToPublic }}
release: don't publish private symbols for 100 years (#39015)
2025-04-21 23:16:42 -05:00
${{ if ne(parameters.publishSymbolsToPublic, true) }}:
symbolExpiryTime: 10 # For private builds, expire symbols within 10 days. The default is 100 years.
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
subscription: $(SymbolPublishingServiceConnection)
symbolProject: $(SymbolPublishingProject)
Reference in New Issue Copy Permalink