[Draft] Add perf-build.yml: per-commit ASP.NET Core build → Build Cache Service

[LoopedBard3]

Draft — fork-staged for review.

What

Adds .azure/pipelines/perf-build.yml — a new Azure DevOps pipeline that builds every commit on main for dotnet/aspnetcore (Windows multi-arch + Linux x64 + Linux arm64) and uploads the per-RID Microsoft.AspNetCore.App.Runtime.{rid} packs to the .NET Performance team's Build Cache Service (BCS) under builds/aspnetcore/buildArtifacts/{sha}/{configKey}/.... dotnet/crank then resolves Microsoft.AspNetCore.App runtime binaries by commit SHA for performance-regression bisection.

Modeled directly on dotnet/runtime's eng/pipelines/performance/perf-build.yml.

Architecture — three-stage shape (mirrors runtime)

RegisterBuild  ─┐  (parallel, writes buildInfo.json per configKey)
build          ─┤  (parallel, produces pipeline artifacts)
                │
UploadArtifacts ┘  (dependsOn: [build, RegisterBuild],
                    uploads archives next to the markers)

• RegisterBuild — delegates to register-build-jobs.yml@performance (companion Generalize BCS upload + register-build templates with repoName parameter dotnet/performance#5241), which writes builds/aspnetcore/buildArtifacts/{sha}/{configKey}/buildInfo.json for each config in parallel with the actual build. Cheap, but matters: it gives this repo BCS-layout symmetry with runtime, so any future dotnet-performance-infra tooling that reads buildInfo.json works uniformly across both repos.

• build — three jobs (Windows multi-arch in one job following ci.yml's Windows_build pattern; Linux x64; Linux arm64 cross-built from x64 host). Each invokes the existing default-build.yml@self template with -pack -all --no-build-java -p:OnlyPackPlatformSpecificPackages=true, then a post-build step unzips the per-RID Microsoft.AspNetCore.App.Runtime.{rid}.{ver}.nupkg into a microsoft.aspnetcore.app.runtime.{rid}/Release/runtimes/{rid}/... layout and zips/tars it as a pipeline artifact.

• UploadArtifacts (internal + IndividualCI/Manual only) — delegates to upload-build-artifacts-jobs.yml@performance (also companion Angular 6 multi project SPA  dotnet/aspnetcore#5241). One template call dispatches into five per-configKey upload jobs:

  buildType:
    - aspnetcore_x64_linux
    - aspnetcore_arm64_linux
    - aspnetcore_x64_windows
    - aspnetcore_arm64_windows
    - aspnetcore_x86_windows
  repoName: aspnetcore
  

  The shared template handles the az storage blob upload against pvscmdupload/$web/builds/aspnetcore/buildArtifacts/{sha}/{configKey}/{file}.

Not extending 1ES.Official

Unlike ci.yml (which ships signed bits) or ci-unofficial.yml (which validates PRs), this pipeline produces intermediate build artifacts that go to a private BCS cache — they aren't signed or redistributed. SDL / PoliCheck / TSA scans add no security value for that workload. Runtime's own perf-build runs as a plain non-1ES pipeline against the same .NET Performance Azure service connection and has done so for years; we follow the same pattern. This drops ~30 LOC of 1ES boilerplate (the 1esPipelines resource, the extends: block, the sdl: config) and lets jobs inherit the pipeline's default pool naturally.

If dnceng/internal AzDO ever rejects a non-1ES pipeline in this project (unverified — we'd be the first non-1ES one in .azure/pipelines/), the fallback is a one-line switch to 1ES.Unofficial.PipelineTemplate.yml (used today by ci-unofficial.yml and identitymodel-helix-matrix.yml).

Atomicity

The MissingBuildsTrigger Azure Function in internal/dotnet-performance-infra indexes only Azure DevOps builds with overall Status == Succeeded. All stages run with the default continueOnError: false, so any RegisterBuild / build / UploadArtifacts failure sinks the overall build to Failed and the Function skips indexing for that SHA. Operator retries the whole build green. The atomic unit is the AzDO build, not the per-config job.

Archive contract (load-bearing)

Per-RID archive root MUST be microsoft.aspnetcore.app.runtime.{rid} (lowercase, matching the canonical name an extracted nupkg lands at). The future aspnetcore-overlay crank PR will hardcode this name in a FindDirectory(extractDir, $"microsoft.aspnetcore.app.runtime.{rid}") call mirroring crank PR 878's runtime overlay. Renaming the archive root breaks every future crank consumer.

Archive contents:

microsoft.aspnetcore.app.runtime.{rid}/
  Release/
    runtimes/{rid}/
      lib/net{X}.0/Microsoft.AspNetCore.*.dll
      native/aspnetcorev2*.dll       (Windows only — ANCM/IIS bits)

configKey set (v1 lock)

aspnetcore_x64_linux, aspnetcore_arm64_linux, aspnetcore_x64_windows, aspnetcore_arm64_windows, aspnetcore_x86_windows. macOS + musl + Linux arm32 deferred to v2 (not current crank perf scenarios). Once uploaded, renaming requires storage-level migration — crank caches latestBuilds.json for 1 hour.

Sequencing / dependencies

1. Generalize BCS upload + register-build templates with repoName parameter dotnet/performance#5241 must merge first — this pipeline resolves register-build-jobs.yml@performance and upload-build-artifacts-jobs.yml@performance through the internal/dotnet-performance AzDO mirror, which only updates after dotnet/performance/main advances.
2. dotnet/aspnetcore PR (this one, when retargeted to upstream) merges.
3. Pipeline definition created in dnceng/internal AzDO; record the pipeline ID.
4. Manually queue one perf-build run; verify three stages run and archives + buildInfo.json land in pvscmdupload/$web/builds/aspnetcore/buildArtifacts/{sha}/{configKey}/.
5. (Future, separate PR.) Update internal/dotnet-performance-infra so MissingBuildsTrigger handles aspnetcore configKeys + the aspnetcore pipeline. After deploy, latestBuilds.json at builds/aspnetcore/latest/main/latestBuilds.json lands on the next 8h tick. End-to-end with crank.

Out of scope (tracked, not done here)

• Crank-side: extend PlatformToBcsConfig with the aspnetcore mapping + add an aspnetcore overlay code path. Separate future crank PR.
• internal/dotnet-performance-infra indexer/schema changes. Separate future PR — needs (a) extending the dispatcher's known config-key list, (b) registering the new aspnetcore pipeline ID, and (c) resolving the builds/{repoName}/ blob-path mystery on the indexer side.
• release/X.Y branches. v1 ships main only.

File-level changes

• Added: .azure/pipelines/perf-build.yml (three-stage, non-1ES)
• Deleted (in a prior commit on this branch): .azure/pipelines/jobs/perf-build-upload-job.yml (functionality replaced by the dotnet/performance shared template)

[LoopedBard3]

Superseded: this perf-build pipeline is being moved into dotnet/performance for perf-team merge control. The performance-hosted version rebuilds aspnetcore from source (it cannot reuse aspnetcore's default-build.yml due to @self resolving to the host repo) and triggers per-commit via a repository-resource CI trigger on the dotnet-aspnetcore mirror. Closing in favor of that work. Branch retained for reference.