[LoopedBard3]

Summary

Avoid rebuilding the same benchmark applications for every matrix entry. Fortunes FastHttp currently spends roughly 42 seconds rebuilding the application for each size/rate combination, despite the load phase being only 15 seconds of warmup plus 15 seconds of measurement.

• Pass Crank's existing build-reuse options directly in the container, gRPC, HttpClient, SignalR, and WebSocket templates. No separate cache profile or test harness is introduced.
• Scope source and build keys to Build.BuildId, refreshing sources/builds for each pipeline run while reusing compatible variants on each agent.
• Also scope cached Docker image tags to the build ID for container applications/databases and gRPC Go servers/clients, preventing interleaved pipeline runs from overwriting each other's images. Non-Docker jobs are unchanged by the image hooks.
• Keep separate identities for Dockerfile variants, gRPC implementations/frameworks, and WebSocket compression builds. Share SignalR's client build between warmup and load.
• Preserve benchmark durations, runtime settings, scheduling, and result-storage configuration. Applications and database containers still start fresh for each benchmark.

The branch is based on aspnet/Benchmarks main.

Validation

Configuration-only validation used the existing Crank CLI without running benchmark agents:

• Expanded and JSON-validated all 541 matrix messages for two pipeline build IDs, including the shared database argument fragment and quoted configuration hooks.
• Resolved 60 real configurations covering 30 variants across two build IDs. Verified compatible native build fingerprints for shared keys, source/build key isolation, Docker image-tag isolation for all four affected roles, and unchanged non-Docker image names.
• Passed all 43 existing pod-scheduler tests, including generated pipeline snapshots.
• Passed staged whitespace checks.

Deployment considerations

No live benchmark timing run has been performed; actual wall-time savings still need to be measured after deployment. Retained builds and images rely on the agents' existing cleanup/restart policy; this change does not add a cache TTL.

[Copilot]

🟡 Changes recommended

Shared Docker tags allow interleaved pipeline runs to reuse another run’s images despite run-scoped cache keys.

1 open issue

• Isolate Docker image tags by build cache ID · New

What changed in this PR

This PR adds per-pipeline build reuse to five benchmark matrices, reducing repeated compilation while preserving benchmark durations and result-storage settings.

Changes:

• Adds run-scoped source and build cache profiles and wires them into CI templates.
• Separates build variants by Docker image, gRPC implementation, framework, and WebSocket compression.
• Adds configuration regression tests and documents cache lifetime and excluded suites.

File	Description
scenarios/​containers.benchmarks.yml	Gives ASP.NET Docker variants distinct image names.
build/​websocket-scenarios.yml	Enables run-scoped WebSocket build reuse.
build/​tests/​test_build_reuse.py	Tests profile wiring, cache isolation, and compatible reuse.
build/​signalr-scenarios.yml	Enables SignalR server and shared client build reuse.
build/​README.md	Documents caching behavior, lifetime, and validation.
build/​job-variables.yml	Defines the shared cache-profile configuration URL.
build/​httpclient-scenarios.yml	Enables build reuse for GET and POST matrices.
build/​grpc-scenarios.yml	Adds implementation identities and enables build reuse.
build/​containers-scenarios.yml	Enables container application and database build reuse.
build/​build-reuse.profile.yml	Defines cache identities and input validation for five suites.

_{Review effort: Balanced}

[DrewScoggins]

LGTM