Publish Checksums to dotnetclichecksums storage account

[wtgodbe]

Resolves #18792. We stopped publishing checksums some time in the 2.1 time frame - this PR turns that feature back on. Validated with https://dev.azure.com/dnceng/internal/_build/results?buildId=520228 (though that build incorrectly prefixed RelativeBlobPath with Dotnet - I've fixed that up in this PR). Still a bit of cleanup to do, but it works as intended.

@dougbu @JunTaoLuo PTAL

CC @Pilchie @mthalman

[wtgodbe]

Will rebase once #19036 is in

[dougbu]

Don't we need checksums for Linux and macOS installers & bundles?

[dougbu]

Please do a trial run on internal queues. Big piece of this won't work except in a "real" build.

[Pilchie]

This looks good to me. We need something for 2.1.x as well right?

[dougbu]

@wtgodbe any internal build or answers to questions above will be much appreciated 😈

[wtgodbe]

Don't we need checksums for Linux and macOS installers & bundles?

That wasn't an original requirement, just the runtime archives & Windows installer executables - #18792 (comment). I did a catch-all in the Windows installer folder because it seemed cleaner than picking-and-choosing the specific output Items we wanted, and more SHA512 files doesn't hurt (e.g. runtime & core-sdk do checksums for their installers). That being said, there's no good reason not to do checksums for those bundles, so I can add them.

Please do a trial run on internal queues. Big piece of this won't work except in a "real" build.

I linked the validation build in the PR description: https://dev.azure.com/dnceng/internal/_build/results?buildId=520228. I'll run another one after applying your feedback.

This looks good to me. We need something for 2.1.x as well right?

Yep, I'll look into what's needed for that tomorrow. It may be pretty different from what I'm doing here

[wtgodbe]

New build: https://dev.azure.com/dnceng/internal/_build/results?buildId=521702

I realized this does do checksums for the OSX/Linux bundles (the tar.gz archives) - it just doesn't do so for the debs/rpms

[dougbu]

it just doesn't do so for the debs/rpms

As long as those aren't needed, sounds good. /cc @mthalman @MichaelSimons

[mthalman]

it just doesn't do so for the debs/rpms

As long as those aren't needed, sounds good. /cc @mthalman Matt Thalman FTE @MichaelSimons Michael Simons (.NET) FTE

Yes, that's fine.

[dougbu]

@wtgodbe please look into the incredibly high number of warnings in your internal build. What gives?

[wtgodbe]

@dougbu those are mostly the Nuget warnings about stable packages w/ prerelease dependencies. They appear to have gone away in the new build, which is rebased on top of your change that fixed that problem.

[wtgodbe]

New internal build looks good, and I've confirmed everything got published to dotnetclichecksums:

@dougbu @mthalman any last concerns?

[dougbu]

No issues except for the new conflict in Publishing.props