Make the dotnet/runtime official build an assetless build

[jkoritzinsky]

Make assetless publishing run in parallel with the Build stage of the official build.

I've moved jobs to the runtime-codeql pipeline (and made that an official pipeline) to ensure that we still have coverage for SDL tools on dotnet/runtime code (per the current VMR plan to have each repo handle their SDL compliance initially).

Also remove the infrastructure around the join job in dotnet/runtime.

Depends on us making the final decision to go with the VMR (and being comfortable removing old infra).

Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2702458&view=results

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This pull request enables assetless publishing to run in parallel with the Build stage for the dotnet/runtime official build while removing the infrastructure around the join job.

• Updated the pipeline template reference to use a common pipeline template with resources.
• Added a new Publish stage with assetless build parameters.

Files not reviewed (5)

• Build.proj: Language not supported
• eng/Publishing.props: Language not supported
• eng/Signing.props: Language not supported
• eng/pipelines/official/pipeline.yml: Language not supported
• eng/pipelines/official/prepare-signed-artifacts.yml: Language not supported

Comments suppressed due to low confidence (2)

eng/pipelines/runtime-official.yml:33

• Consider reviewing the use of multiple extends templates to ensure that there is no parameter conflict or ambiguity between the official and common pipeline templates.

template:  /eng/pipelines/common/templates/pipeline-with-resources.yml

eng/pipelines/runtime-official.yml:167

• Verify that the pool selection and demand criteria match the requirements for assetless builds, ensuring the correct agent is used.

demands: ImageOverride -equals 1es-windows-2022

[ViktorHofer]

LGTM aside from one comment. Post merge, CG will need to be reconfigured to now analyze the codeql pipeline instead. cc @ericstj for awareness

[ericstj]

@jkoritzinsky can you show me a CodeQL build that's running all the tools appropriately? Let's make sure that's set up correctly, or we have bugs on any issues before we merge this.

As for CG - that doesn't require assets and can stay running on official build if it "builds the most". I'm not sure how much CodeQL builds so it's unclear if that's the right place for those other tools or not. Let's consider case-by-case. It also might be good to add a doc that records these decisions as intentional.

[jkoritzinsky]

runtime-codeql run here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2703057&view=results

[jkoritzinsky]

New build link: https://dev.azure.com/dnceng/internal/_build/results?buildId=2703060&view=results

[jkoritzinsky]

New build link: https://dev.azure.com/dnceng/internal/_build/results?buildId=2703410&view=results