Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink distribution mechanisms for known public releases #463

Open
YuliiaKovalova opened this issue Apr 10, 2024 · 0 comments
Open

Rethink distribution mechanisms for known public releases #463

YuliiaKovalova opened this issue Apr 10, 2024 · 0 comments
Labels

Comments

@YuliiaKovalova
Copy link
Member

YuliiaKovalova commented Apr 10, 2024

This tool has two primary usage modes:

  • acquire binaries for one of the publically-available releases
  • acquire binaries for a very specific version (e.g. nightlies) from a customizable location

For both cases we construct a URL with a particular layout based on the request parameters, and this URL redirects to a location with the binaries to download. The location we've stored these binaries has a few known issues, specifically for users with certain network configurations.

I propose that for the first use case, "download the latest 8.0 SDK for the Linux platform, x64 architecture", we should download the binaries from the .NET Release Manifest that the release team publishes for each monthly release.

These manifests support

  • detecting support status of a 'channel' - for example in the following JSON we can see that the 8.0 channel is currently considered in 'active' status, and that it is an lts release:
{
            "channel-version": "8.0",
            "latest-release": "8.0.4",
            "latest-release-date": "2024-04-09",
            "security": true,
            "latest-runtime": "8.0.4",
            "latest-sdk": "8.0.204",
            "product": ".NET",
            "release-type" : "lts",
            "support-phase": "active",
            "eol-date": "2026-11-10",
            "releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/releases.json"
}
  • discovering the latest release for a channel - for example in the above JSON the releases.json property provides a URL that links to the releases for that version. If we follow that URL, we get another manifest full of entries like this:

image

Here we can see clearly that we can find the list of assets by filtering on the desired .NET RID. Once we have that release we can easily get

  • a download url that uses centralized download.visualstudio.microsoft.com links, which are more battle-tested
  • a hash that we can use to validate the download is correct

We should only use this file when

  • The user hasn't specified a custom -AzureFeed
  • The user requests an SDK/Runtime/Asp.Net Runtime via the --channel and/or --quality options
    • The LTS/STS channels do not use quality, and should map to the latest 'stable' release of that kind in the release index
    • If --quality is daily then the release manifest cannot be used and the Azure Feed should be used
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant