ACR-based SDK distribution

[CodingIsBliss]

Summary

Multiple ways to pull SDKs from different resources based on environment variables:

1. ORYX_ENABLE_EXTERNAL_ACR_SDK_PROVIDER
   Oryx -> Socket -> ACR

2. ORYX_ENABLE_EXTERNAL_SDK_PROVIDER (Existing flow for App Services)
   Oryx -> Socket -> Storage Account

3. ORYX_ENABLE_ACR_SDK_PROVIDER
   Oryx -> ACR

4. Oryx -> Storage Account

Priority and Fallback order

1. Oryx -> Socket -> ACR
2. Oryx -> Socket -> Storage Account
3. Oryx -> ACR
4. Oryx -> Storage Account

Review Guide

Start at DefaultPlatformsInformationProvider.cs → GetPlatformsInfo(). This is the entry point that detects platforms and logs SDK provider status (new). It calls platform.Detect() for each platform.

Follow the flow for each platform:

Python — PythonPlatform.Detect() → ResolveVersions() → GetInstallerScriptSnippet()
PHP — PhpPlatform → InstallPhp() / InstallPhpComposer() (refactored with ACR fallback chain)
Node — NodePlatform → same pattern as Python
DotNet — DotnetCorePlatform → has extra SDK↔Runtime version mapping via compound ACR tags
Key new shared components:

Key new shared components:

AcrSdkProvider.cs — Direct OCI API client (downloads SDK tarballs from ACR)
OciRegistryClient.cs — HTTP client for OCI Distribution API
ExternalAcrSdkProvider.cs / ExternalAcrVersionProviderBase.cs — Socket-based ACR path
Modified existing files:

PlatformInstallerBase.cs → skipSdkBinaryDownload block added for ACR tarball lookup + extraction

Some other points:

1. PHP uses a different pattern than Python/Node/DotNet
   Python, Node, DotNet: GetInstallerScriptSnippet returns a string — each TryInstall* returns the script or null
   PHP: Uses StringBuilder — each TryInstall* appends directly to the builder and returns bool. This is because PHP installs two things (PHP + Composer) in a single GetInstallerScriptSnippet call
2. DotNet ACR tags use compound format
   All other platforms: {osFlavor}-{version} (e.g., noble-3.14.3)
   DotNet: {osFlavor}-{sdkVersion}_{runtimeVersion} (e.g., noble-10.0.201_10.0.5) because .NET requires runtime→SDK version mapping. DotNetCoreAcrVersionProvider parses this; AcrSdkProvider passes runtimeVersion as an optional parameter to construct the correct tag
3. OCI layer unwrapping done in C# (AcrSdkProvider), not bash (PlatformInstallerBase)
   FROM scratch; COPY sdk.tar.gz / produces a layer that wraps the tarball inside a tar
   AcrSdkProvider.ExtractFileFromTar extracts the inner SDK tarball using System.Formats.Tar.TarReader — so by the time PlatformInstallerBase runs, the file at dynamicPath is already the raw SDK tarball, same as what CDN/blob providers produce
4. Four SDK sources with independent fallback
   Each provider is independent — if one fails, the next is tried without any state leaking
   Order: External-ACR (socket→host→ACR) → External-SDK (socket→host→blob) → Direct-ACR (OCI API) → CDN
   The first two are controlled by the App Service platform; the last two are Oryx-native
5. Token auth for anonymous ACR
   Even "anonymous pull" ACR registries require a bearer token exchange — OciRegistryClient handles this transparently with per-scope token caching

Testing

With ACR Provider enabled (direct ACR pull from Oryx)

• Dotnet

• Python

• Php

• Nodejs

[sarsharma]

Maybe we need 2 config flags here?
ORYX_ENABLE_EXTERNAL_ACR_SDK_PROVIDER
ORYX_ENABLE_ACR_SDK_PROVIDER

[surenderssm]

Can we list the scenarios which were used to test these changes?

[siriande]

The Try...FromExternalSdkProvider and Try...FromExternalAcrSdkProvider methods look essentially identical across node, .NET and PHP (just swapping platform name strings and installer references etc.). Can we have a shared helper?

[sarsharma]

Just adding this comment here to update description with testing details