Mirrors/PowerToys
1
0
Fork 0
mirror of https://github.com/microsoft/PowerToys.git synced 2026-04-10 13:35:31 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
a0ac7efd2d878411260be11a4a3d2c8fb30b6034
PowerToys/.pipelines/v2/ci.yml

53 lines
1.1 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:
batch: true
branches:
include:
- main
- stable
Removing Markdown exclude (#35380) Update ci.yml
2024-10-11 11:56:55 -07:00
# paths:
# exclude:
# - doc/*
# - temp/*
# - tools/*
# - '**.md'
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
pr:
branches:
include:
- main
- stable
Removing Markdown exclude (#35380) Update ci.yml
2024-10-11 11:56:55 -07:00
# paths:
# exclude:
# - '**.md'
# - doc
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)
parameters:
- name: buildPlatforms
type: object
default:
- x64
- arm64
- name: enableMsBuildCaching
type: boolean
displayName: "Enable MSBuild Caching"
Re-enable MSBuildCache (#40261) Re-enable MSBuildCache
2025-07-10 04:08:28 -07:00
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
displayName: "Run Tests"
default: true
[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
extends:
template: templates/pipeline-ci-build.yml
parameters:
buildPlatforms: ${{ parameters.buildPlatforms }}
Re-enable MSBuildCache (#40261) Re-enable MSBuildCache
2025-07-10 04:08:28 -07:00
${{ if eq(variables['System.PullRequest.IsFork'], 'False') }}:
enableMsBuildCaching: ${{ parameters.enableMsBuildCaching }}
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
runTests: ${{ parameters.runTests }}
[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
useVSPreview: ${{ parameters.useVSPreview }}
Reference in New Issue Copy Permalink