[Installer -> SDK] SDK does not produce MSFT SDK Tarball

[ellahathaway]

Related to #40451 and dotnet/source-build#4357

The source-build SDK diff test rely on the MSFT tarball which is produced as a blob artifact in installer builds. Currently, the sdk diff test runs (internal Microsoft link) on the main-sdk branch are failing due to the MSFT tarball not being found in the associated sdk build's blob artifacts:

/usr/bin/bash --noprofile --norc /mnt/vss/_work/_temp/127fdebc-dd70-435d-8b41-636ac68a871b.sh
Microsoft SDK tarball does not exist in '/mnt/vss/_work/1/Artifacts'. The associated build https://dev.azure.com/dnceng/internal/_build/results?buildId=2441260 might have failed.

##[error]Bash exited with code '1'.
Finishing: Prepare Tests

To resolve this, we either need to produce the needed artifacts or refactor the SDK diff tests to not rely on the tarball.

[ViktorHofer]

Would it be acceptable to disable this validation until the sdk official pipeline produces these assets? Alternatively, could we fetch the sdk archive from the installer pipeline meanwhile?

[ellahathaway]

I personally don't mind leaving the runs on the main-sdk branch enabled so long as there's a plan to fix this issue in the future.

What is the ETA for having the sdk official pipeline produce this artifact? If it's happening soon, I don't see significant value in fetching the sdk archive from installer in the meanwhile.

[ViktorHofer]

The goal is to complete the repo merge before the next preview snap. So, roughly three weeks.

[ellahathaway]

Hm okay - that's a bit longer than I had expected. I think that these tests are important, so I'll start working on the changes to pull the sdk archive from the installer repo.

[ViktorHofer]

I'll start working on the changes to pull the sdk archive from the installer repo.

Alternatively we could already push the msft sdk from the dotnet-sdk-official pipeline but into a specific pipeline artifact folder or change the relative blob path (i.e. use sdk-installer as the product name) so that it doesn't clash with the installer one. That would be a ~1 liner to implement (in sdk's Publishing.props). cc @MiYanni @mmitche

sdk/eng/Publishing.props

Line 205 in 3b7468f

<RelativeBlobPath>$(BlobStoragePartialRelativePath)/$(FullNugetVersion)/$([System.String]::Copy('%(Filename)%(Extension)'))</RelativeBlobPath>

[MiYanni]

I'll look into getting this produced today. I don't know what's necessary for it.

Edit: Looks like it is basically that the non-Windows jobs run. All the logic to create them is already there. We just need the jobs.

[ellahathaway]

Edit: Looks like it is basically that the non-Windows jobs run. All the logic to create them is already there. We just need the jobs.

Ok great, thanks! Let me know if/how I can help with adding the jobs.

[MiYanni]

I've decided that I want to clean up the SDK pipeline before adding all these other jobs to it. So, I'm doing that first. It is gonna take some time as the 1ESPT stuff makes it a bit more complicated to design.