Pass -productBuild and -sourceBuild switches from the VMR orchestrator to the repos instead of /p:DotNetBuildRepo=true and /p:DotNetBuildSourceOnly=true

[ViktorHofer]

tools.ps1/sh might need to condition on whether the build is a product build or source-build. Tools.ps1/sh need to parse the $properties string array today which isn't great as not all repos set that. We should pass the -productBuild switch in when building the repos and then remove these code paths:

• https://github.com/dotnet/arcade/blob/6eb545ab682b04dc72cf574252b7843ec657dd99/eng/common/tools.ps1#L71
• https://github.com/dotnet/arcade/blob/6eb545ab682b04dc72cf574252b7843ec657dd99/eng/common/tools.ps1#L859 (the DotNetBuildRepo part)
• https://github.com/dotnet/arcade/blob/6eb545ab682b04dc72cf574252b7843ec657dd99/eng/common/tools.sh#L510 (the DotNetBuildRepo part)

This became more important recently with the addition of the source-build condition on the NUGET_PACKAGES directory selection: https://github.com/dotnet/dotnet/blob/cdd3eef3e3053cb776f066fde7b2f5a2b7ebe886/src/arcade/eng/common/tools.sh#L63-L69

[mmitche]

This is a good idea, though It will be necessary to implement this switch in any repo that has its own build entry point scripts:

• aspnetcore
• nuget.client
• roslyn
• fsharp?
• runtime

[ViktorHofer]

AFAIK only in the repos that don't forward switches to the Arcade build scripts. I.e. runtime just invokes eng/common/build.ps1/sh underneath and the switch should automatically be respected. AspNetCore doesn't do that and I assume they will need to react.

[mmitche]

Fit and finish

[ViktorHofer]

This is needed in fsharp as they select the solution file to build in their script files instead of in Arcade. Essentially this is needed to remove this define from DotNetBuild.props which today just appends the Projects property which results in them being passed in twice. The latter one wins which is why this works today.

We should pass the productBuild switch in and then set the solution file in the scripts.

[ViktorHofer]

Regarding my above comment about fsharp: This works for the VMR build but not for the repo source-build because there, we can't pass additional arguments in, i.e. the --sourceBuild or the --productBuild switch.

We should do the following (which I discussed with @mmitche offline a while ago):

1. Add the -productBuild and -sourceBuild (on Unix) switches to the repositories that don't use Arcade scripts nor pass down args to the arcade scripts (Example: no action needed for runtime because it passes args down to the Arcade scripts).
2. Update the VMR orchestrator to pass the flags in, instead of the properties: https://github.com/dotnet/dotnet/blob/3bf48e0324dc2335f5c7ea606ea3664ab1cdd375/repo-projects/Directory.Build.props#L142 & https://github.com/dotnet/dotnet/blob/3bf48e0324dc2335f5c7ea606ea3664ab1cdd375/repo-projects/Directory.Build.props#L150
3. Update the repo source build YML to pass these flags in, instead of the properties: https://github.com/dotnet/arcade/blob/36f91467d150caf4f8ca0008f039d746bc03017b/eng/common/core-templates/steps/source-build.yml#L94-L95

@MichaelSimons do you have someone who could help with that? This would be an improvement to both the VMR and the repo source-build jobs. I doubt this is much work. Probably just a handful of repos. I'm taking care of fsharp so maybe just aspnetcore, nuget-client and roslyn.

[MichaelSimons]

@MichaelSimons do you have someone who could help with that?

Yes as part of the fit and finish work. I am hesitant to assign a specific person as I see us prioritizing the fit and finish work and having people grab the top priority work first.

[ViktorHofer]

In my case, I'm already looking at Fit & Finish items as I don't have any P4 critical items assigned. I was wondering if the same is true for someone on your team.

[MichaelSimons]

In my case, I'm already looking at Fit & Finish items as I don't have any P4 critical items assigned. I was wondering if the same is true for someone on your team.

No it is not the case for my team.