mirror of
https://github.com/microsoft/terminal.git
synced 2025-12-19 18:11:39 -05:00
69eff7e9fd
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.
- **Building the project produces a `bin` directory.** That `bin`
directory is therefore the primary currency of the build. Jobs will
either produce or consume `bin` if they want to do anything with the
build outputs.
- 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 Terminal 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.
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.
- Optionally signs the output and produces a bill of materials.
- Admittedly has a lot going on.
- `job-build-package-wpf`
- Takes a list of build configurations and platforms.
- Consumes the `build-` artifact for every config/platform
possibility, plus one for "Any CPU" (hardcoded; this is where the
.NET code builds)
- Produces one `wpf-nupkg-CONFIG` for each configuration, merging
all platforms.
- Optionally signs the output and produces a bill of materials.
- `job-merge-msix-into-bundle`
- Takes a list of build configurations and platforms.
- Consumes the `build-` artifact for every config/platform
- Produces one `appxbundle-CONFIG` for each configuration, merging
all platforms for that config into one `msixbundle`.
- Optionally signs the output and produces a bill of materials.
- `job-package-conpty`
- Takes a list of build configurations and platforms.
- Consumes the `build-` artifact for every config/platform
- Produces one `conpty-nupkg-CONFIG` for each configuration, merging
all platforms.
- Optionally signs the output and produces a bill of materials.
- `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-run-pgo-tests`
- Just like the above, but runs tests where `IsPgo` is `true`
- Collects all of the PGO counts and publishes a `pgc-intermediates`
artifact for that platform and configuration.
- `job-pgo-merge-pgd`
- Takes **one** build config and multiple platforms.
- Consumes `build-$platform-CONFIG` for each platform.
- Consumes `pgc-intermediates-$platform-CONFIG` for each platform.
- Merges the `pgc` files into `pgd` files
- Produces a new `pgd-` artifact.
- `job-pgo-build-nuget-and-publish`
- Consumes the `pgd-` artifact from above.
- Packs it into a `nupkg` and publishes it.
- `job-submit-windows-vpack`
- Only expected to run against `Release`.
- Consumes the `appxbundle-CONFIG` artifact.
- Publishes it to a vpack for Windows to consume.
- `job-check-code-format`
- Does not use artifacts. Runs `clang-format`.
- `job-index-github-codenav`
- Does not use artifacts.
Fuzz submission is broken due to changes in the `onefuzz` client.
I have removed the compliance and security build because it is no longer
supported.
Finally, this pull request has some additional benefits:
- I've expanded the PGO build phase to cover ARM64!
- We can remove everything Helix-related except the WTT parser
- We no longer depend on Helix submission or Helix pools
- The WPF control's inner DLLs are now codesigned (#15404)
- Symbols for the WPF control, both .NET and C++, are published
alongside all other symbols.
- The files we submit to ESRP for signing are batched up into a single
step[^1]
Closes #11874
Closes #11974
Closes #15404
[^1]: This will have to change if we want to sign the individual
per-architecture `.appx` files before bundling so that they can be
directly installed.
51 lines
3.2 KiB
XML
51 lines
3.2 KiB
XML
<Project>
|
|
<PropertyGroup>
|
|
<NuGetPackageDirectory>$(MSBuildThisFileDirectory)..\..\packages</NuGetPackageDirectory>
|
|
<PkgMicrosoft_PGO_Helpers_Cpp>$(NuGetPackageDirectory)\Microsoft.Internal.PGO-Helpers.Cpp.0.2.34</PkgMicrosoft_PGO_Helpers_Cpp>
|
|
</PropertyGroup>
|
|
|
|
<!-- Get version information -->
|
|
<Import Project="$(MSBuildThisFileDirectory)..\..\custom.props" />
|
|
|
|
<PropertyGroup>
|
|
<!-- Optional, defaults to main. Name of the branch which will be used for calculating branch point. -->
|
|
<PGOBranch>main</PGOBranch>
|
|
|
|
<!-- Mandatory. Name of the NuGet package which will contain PGO databases for consumption by build system. -->
|
|
<PGOPackageName>Microsoft.Internal.Windows.Terminal.PGODatabase</PGOPackageName>
|
|
|
|
<!-- Mandatory. Major version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
|
|
<PGOPackageVersionMajor>$(VersionMajor)</PGOPackageVersionMajor>
|
|
|
|
<!-- Mandatory. Minor version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
|
|
<PGOPackageVersionMinor>$(VersionMinor)</PGOPackageVersionMinor>
|
|
|
|
<!-- Mandatory, defaults to 0. Patch version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
|
|
<PGOPackageVersionPatch>0</PGOPackageVersionPatch>
|
|
|
|
<!-- Optional, defaults to empty. Prerelease version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
|
|
<PGOPackageVersionPrerelease></PGOPackageVersionPrerelease>
|
|
|
|
<!-- Mandatory. Path to nuget.config file for the project. Path is relative to where the props file will be. -->
|
|
<PGONuGetConfigPath>$(MSBuildThisFileDirectory)..\..\nuget.config</PGONuGetConfigPath>
|
|
|
|
<!-- Mandatory. Path to PGO database NuSpec, see section below. -->
|
|
<PGONuspecPath>$(MSBuildThisFileDirectory)Terminal.PGO.DB.nuspec</PGONuspecPath>
|
|
|
|
<!-- Optional, defaults to true. Should verification result in build failure or error? -->
|
|
<PGOVerifyFailureTreatedAsError>true</PGOVerifyFailureTreatedAsError>
|
|
|
|
<!-- Optional, defaults to $(IntDir)\Nuspec. Temporary path where PGD files are copied to. -->
|
|
<PGONuspecBasePath>$(PGDPathForAllArch)</PGONuspecBasePath>
|
|
|
|
<!-- Optional, defaults to true. Specifies whether to use default information for PGD files. -->
|
|
<PGOUseDefaultPGDFileInfo>true</PGOUseDefaultPGDFileInfo>
|
|
|
|
<!-- Copying the PGO runtime brings along a CRT. If we do that under normal circumstances, WAPPROJ will get its grubby hands on it and mess up all the CRT shenanigans we have to pull to make MSIX packages happy. So only pull it in for Instrument builds.-->
|
|
<PGOCopyRuntime>false</PGOCopyRuntime>
|
|
<PGOCopyRuntime Condition="'$(PGOBuildMode)' == 'Instrument'">true</PGOCopyRuntime>
|
|
</PropertyGroup>
|
|
|
|
<!-- Do not import PGO-Helpers props here, as it is too early to detect the C++ tools directory -->
|
|
</Project>
|