[build] Don't download CoreCLR product for Mono runtime tests

[lambdageek]

Shouldn't be needed after #62652

Contributes to #51584, I think

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Shouldn't be needed after #62652

Contributes to #51584, I think

Author:	lambdageek
Assignees:	-
Labels:	area-Infrastructure-mono
Milestone:	-

[lambdageek]

@akoeplinger @safern How are these artifacts actually used?

Are there other pipeline steps that consume CoreCLR artifacts during Mono runs?

[lambdageek]

Hmm... what target creates MonoProduct___OSX_x64_release.tar.gz - I think I need to update it to put corerun in that tgz

I guess it's this step:

runtime/eng/pipelines/mono/templates/build-job.yml

Lines 161 to 170 in 2658a0b

	# Publish product output directory for consumption by tests.
	- template: /eng/pipelines/common/upload-artifact-step.yml
	parameters:
	rootFolder: $(buildProductRootFolderPath)
	includeRootFolder: false
	archiveType: $(archiveType)
	tarCompression: $(tarCompression)
	archiveExtension: $(archiveExtension)
	artifactName: $(buildProductArtifactName)
	displayName: 'product build'

And it's zipping up this directory:

runtime/eng/pipelines/mono/templates/xplat-pipeline-job.yml

Lines 73 to 74 in 2658a0b

	- name: buildProductRootFolderPath
	value: '$(Build.SourcesDirectory)/artifacts/bin/mono/$(osGroup).$(archType).$(buildConfigUpper)'

[lambdageek]

Seems pretty clear this won't work. We will return to it once we have a strategy.

At the moment, though, we don't think the Mono runs are using CoreCLR: the https://github.com/dotnet/runtime/blob/main/src/tests/baseservices/mono/runningmono.cs test is passing, and the Core_Root generation is still taking the runtime flavor into account

runtime/eng/pipelines/common/templates/runtimes/run-test-job.yml

Lines 294 to 298 in 2658a0b

	# Compose the Core_Root folder containing all artifacts needed for running
	# CoreCLR tests. This step also compiles the framework using Crossgen / Crossgen2
	# in ReadyToRun jobs.
	- script: $(Build.SourcesDirectory)/src/tests/build$(scriptExt) generatelayoutonly $(logRootNameArg)Layout $(runtimeFlavorArgs) $(crossgenArg) $(buildConfig) $(archType) $(crossArg) $(priorityArg) $(librariesOverrideArg)
	displayName: Generate CORE_ROOT

So we're just downloading a bigger tarball than we otherwise would. We're not configuring the test runs incorrectly.