Everytime the jdk gets updated on build machines, VMR builds break and need a manual update in aspnetcore

[ViktorHofer]

See dotnet/sdk#45822 for more details. I wonder if we really need to specify the exact jdk version that must be available on the build agent. As long as we do that, we keep breaking the VMR and aspnetcore builds with every update.

Arcade has support for finding tools on the machine and promoting them to PATH by using "latest" as the version in global.json. It doesn't attempt to download or install it (anymore) - it must already be available. But that's a necessity anyway for our build agents that are managed by dnceng and our docker images that we control.

Based on dotnet/aspnetcore#58465 (comment), the aspnetcore team still wants a local option to install a version of the jdk, i.e. by invoking a script.

cc @mmitche @wtgodbe @BrennanConroy @akoeplinger

[wtgodbe]

It looks like we own the blob storage where these native tools are hosted - is there an LKG link? We could just update aspnetcore's global.json to use latest, use the install-tools-native script in CI, and update https://github.com/dotnet/aspnetcore/blob/e0e0224d744e6219849538cf9ce5dd3db1ccd658/eng/scripts/InstallJdk.ps1#L43 to use the LKG link

[ViktorHofer]

It doesn't attempt to download or install it (anymore) - it must already be available. But that's a necessity anyway for our build agents that are managed by dnceng and our docker images that we control.

On CI we shouldn't download the toolset. It's a requirement that it is already preinstalled on the image.

[wtgodbe]

On CI we shouldn't download the toolset. It's a requirement that it is already preinstalled on the image.

Not sure I see what you're getting at - my suggestion was that we switch to specifying latest in global.json so that we can utilize the arcade support for finding what's already on the machine; and, if there's an LKG link in our blob storage, we update aspnetcore's InstallJdk.ps1 script to ignore global.json, and instead grab that LKG link. That should satisfy both scenarios

[ViktorHofer]

I probably misunderstood you. Which blob storage are you referring to? I don't think that we still host native tools, do we?

[wtgodbe]

I'm just basing that assumption off of our InstallJdk script - we download from https://netcorenativeassets.blob.core.windows.net/resource-packages/external/windows/java/microsoft-jdk-${JdkVersion}-windows-x64.zip

[wtgodbe]

Actually, even on that blob storage there is no 11.0.25, so maybe it's no longer maintained. We could switch to using something like https://download.oracle.com/java/21/latest/jdk-21_windows-x64_bin.zip in InstallJdk, but then we'd no longer be testing in Helix with the same version we do local/CI builds with (though it looks like this is already the case today: https://github.com/dotnet/aspnetcore/blob/e0e0224d744e6219849538cf9ce5dd3db1ccd658/eng/targets/Helix.targets#L3-L4).

@halter73 @BrennanConroy how strong is our desire to match Java versions everywhere? I think that'd be hard to do if CI builds were saying "Use whatever's on the build machine", as that'd be constantly (though not frequently) changing

[ViktorHofer]

Closing as aspnetcore now uses "latest": https://github.com/dotnet/aspnetcore/blob/bd4a06387dec0939c9afd7beb1f547fd93ad9f6c/global.json#L27