Investigate if crossdac packaging can be built per configuration

[steveisok]

In order to make the runtime more source build friendly, we need to try to eliminate as many "join points" as possible in the official build. We need to determine if it's even possible to split out crossdac packaging per configuration.

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

Issue Details

---

In order to make the runtime more source build friendly, we need to try to eliminate as many "join points" as possible in the official build. We need to determine if it's even possible to split out crossdac packaging per configuration.

Author:	steveisok
Assignees:	ViktorHofer
Labels:	area-Infrastructure
Milestone:	8.0.0

[jkoritzinsky]

With the new support for step targets and the recent refactoring I did for container resources, as well as Linux Containers on Windows support, we have the ability to make the cross-dac packaging step fully independent of the build job, or alternatively, do the cross-dac build as part of the product build.

[steveisok]

Thanks @jkoritzinsky! Good enough for me.

[jkoritzinsky]

Do we want to keep this open to track doing this work, or do we want to open a new issue tracking the work?

[ViktorHofer]

Let's keep this open to track the work.

[ViktorHofer]

@jkoritzinsky when you say step targets, are you referring to templateContext?

[jkoritzinsky]

No, I’m referring to the ability to use the target property on a step to run it in a different named container. Here’s the place we use it today:

runtime/eng/pipelines/installer/jobs/steps/build-linux-package.yml

Line 22 in 6ee57c0

target: ${{ parameters.target }}

[jkoritzinsky]

cc: @hoyosjs

In the infra standup today, we discussed moving the cross-DAC build/package job into a separate pipeline along with the workloads job as both of them produce intermediate artifacts that we do not ship to customers (cross-DAC is for the symbol server only and the workloads job only produces assets that we insert into Visual Studio).