Arcade: Replace the 'latest' links with something more sturdy

[mmitche]

• Is this issue blocking: yes
• Is this issue causing unreasonable pain: yes

---

The latest link in various repos point to blobs in various repos based on the latest build. This is typically done by copying the build output to a set of -latest- files in blob storage.

This is a bad practice for a number of reasons:

• The copy strips off the version info of the file
• The target location in blob storage is based in source. Which means it branches with the source. A custom build run on someone's random branch could accidentally overwrite the latest links.

Instead, what we should do is:

1. For each channel that is public, automatically generate a set of aka.ms links for all published blobs, with the channel info in the link. For instance:

aka.ms/dotnet/dotnet3/sdk/sdk-x86.zip -> https://dotnetcli.blob.core.windows.net/dotnet/sdk/sdk-x86-12346.zip

This would redirect to the target blob location. At the same time, this also gives us an an opportunity to generate a README.md which could be checked into a repo, update a web page, etc.

This should be simple to implement and no changes should be required in the repos (though they can remove their existing latest copy steps when dependent systems are updated)

[mmitche]

/cc @dagood @dougbu @livarcocc @JohnTortugo @markwilkie

[dagood]

-The copy strips off the version info of the file
+The copy strips off the version info of the blob name

A custom build run on someone's random branch could accidentally overwrite the latest links.

Not true for Core-Setup. The dev would also have to configure their random branch to have a default assignment to the BAR channel associated with the dotnetcli 'latest' channel.

Can't speak for other repos' implementations.

This should be simple to implement and no changes should be required in the repos (though they can remove their existing latest copy steps when dependent systems are updated)

It sounds like Core-Setup would need to change to use Arcade's blob publish infra. (The implementation ended up custom because the functionality arrived in Arcade too late.) Is this true?

---

That said, I agree this sounds like a good approach to enable stable links with Arcade publishing.

[mmitche]

It sounds like Core-Setup would need to change to use Arcade's blob publish infra. (The implementation ended up custom because the functionality arrived in Arcade too late.) Is this true?

I think so? Certainly for .NET 5 the combined repo should use arcade's implementation, which means it will happen transparently. For .NET 3.x, it would still be good to get on a common publish infra, now that the infra is available in arcade.

[mmitche]

Not true for Core-Setup. The dev would also have to configure their random branch to have a default assignment to the BAR channel associated with the dotnetcli 'latest' channel.

Right, this is mainly a problem for core-sdk

[dougbu]

This is typically done by copying the build output to a set of -latest- files in blob storage.

What "typically" does this copying?

With ASP.NET Core using the basic Arcade post-build infrastructure, are we affected at all? (Our customizations are fairly localized and don't extend to added stages or anything of that ilk.)

[dagood]

I believe "latest" channel publishing stopped working for ASP.NET Core at some point and it's no longer done by anything for that repo: https://github.com/aspnet/AspNetCore/issues/6509, https://github.com/aspnet/AspNetCore/pull/6955.

[mmitche]

@dougbu core-sdk and core-setup. I think aspnetcore is not affecting and will just gain from automatic aka.ms links

[ViktorHofer]

@mmitche any progress on your proposal? We just removed our download table in dotnet/runtime because the links were outdated since the consolidation.

[mmitche]

It keeps getting pre-empted and back-burnered. I'll see whether I can dig up some more time this week.

[dagood]

I've gone ahead and added the issue template to the desc, with this:

• Is this issue blocking: yes
• Is this issue causing unreasonable pain: yes

The download table is the only reasonable way for external dotnet/runtime contributors to get the signed daily runtime installers.