Skip to content

Conversation

@directhex
Copy link
Contributor

latest is not supported by Arcade, and there's no latest archive in the Azure blob store, so force the most recent supported value here.

CommonLibrary\DownloadAndExtract : Download failed from https://netcorenativeassets.blob.core.windows.net/resource-packages/external/windows/cmake/cmake-latest-win64-x64.zip At C:\d\source-indexer\bin\repo\sdk\eng\common\native\install-tool.ps1:90 char:22 
`latest` is not supported by Arcade, and there's no `latest` archive in the Azure blob store, so force the most recent supported value here. ``` CommonLibrary\DownloadAndExtract : Download failed from https://netcorenativeassets.blob.core.windows.net/resource-packages/external/windows/cmake/cmake-latest-win64-x64.zip At C:\d\source-indexer\bin\repo\sdk\eng\common\native\install-tool.ps1:90 char:22 ```
@ghost ghost added Area-Infrastructure untriaged Request triage from a team member labels Jun 7, 2024
@directhex
Copy link
Contributor Author

Winforms has the same dotnet/winforms#11490

@ericstj
Copy link
Member

ericstj commented Jun 7, 2024

Adding some folks for review so they are aware of this dependency and it's need to update. Looks like @joeloff added in dotnet/installer@3c87114#diff-8df3cd354bc584349d04ad5675b33c042d8b99b741b8b95af394c55e0f5001bfR11

@joeloff
Copy link
Member

joeloff commented Jun 7, 2024

Arcade docs said it should work

Modify your global.json's native-tools section to change the version of your tools to one of the following values:
latest (e.g. "cmake": "latest") – Grabs the latest version of the tool on the machine; this should be what you use in the majority of cases

I'm fine with going back to a specific version, but shouldn't this have failed previously?

@directhex was there a change in Arcade to stop supporting it? It definitely used to work before. I don't see how this is failing everywhere all at once unless some other change was made to the blob storage. Has anyone pinged eng/FR to confirm?

},
"native-tools": {
"cmake": "latest"
"cmake": "3.21.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI there's a PR to bump to 3.26 in runtime: dotnet/runtime#103088

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not via global.json by the look of it. There's no valid cmake-3.26.0-win64-x64.zip in the blob store.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah we don't use global.json for native tools

@directhex
Copy link
Contributor Author

Arcade docs said it should work

Modify your global.json's native-tools section to change the version of your tools to one of the following values: latest (e.g. "cmake": "latest") – Grabs the latest version of the tool on the machine; this should be what you use in the majority of cases

I'm fine with going back to a specific version, but shouldn't this have failed previously?

@directhex was there a change in Arcade to stop supporting it? It definitely used to work before. I don't see how this is failing everywhere all at once unless some other change was made to the blob storage. Has anyone pinged eng/FR to confirm?

Dunno what to say. Maybe there's multiple bits of tooling which parse global.json and install cmake from it - the PowerShell stuff in eng/common/native definitely doesn't support latest, and that's what's being hit in the builds source-indexer is trying to do. https://github.com/dotnet/arcade/blob/main/eng/common/native/install-tool.ps1#L63 just uses the version string verbatim to construct a URL, and there's no files with -latest- in the filename in the cmake blob storage.

The list I was given for the contents of the file store is:

external/windows/cmake/cmake-3.11.1-win32-x86.zip external/windows/cmake/cmake-3.11.1-win64-x64.zip external/windows/cmake/cmake-3.12.2-win64-x64.msi external/windows/cmake/cmake-3.14.2-win32-x86.msi external/windows/cmake/cmake-3.14.2-win32-x86.zip external/windows/cmake/cmake-3.14.2-win64-x64.msi external/windows/cmake/cmake-3.14.2-win64-x64.zip external/windows/cmake/cmake-3.14.5-win32-x86.zip external/windows/cmake/cmake-3.14.5-win64-x64.zip external/windows/cmake/cmake-3.15.5-win32-x86.zip external/windows/cmake/cmake-3.15.5-win64-x64.zip external/windows/cmake/cmake-3.16.4-win32-x86.zip external/windows/cmake/cmake-3.16.4-win64-x64.zip external/windows/cmake/cmake-3.17.3-win32-x86.zip external/windows/cmake/cmake-3.17.3-win64-x64.zip external/windows/cmake/cmake-3.18.3-win64-x64.msi external/windows/cmake/cmake-3.21.0-win32-x86.zip external/windows/cmake/cmake-3.21.0-win64-x64.zip external/windows/cmake/cmake-3.21.7-windows-x64.zip external/windows/cmake/cmake-3.22.1-win64-x64.msi external/windows/cmake/cmake-3.22.1-windows-x64.msi external/windows/cmake/cmake-3.22.3-windows-x64.zip external/windows/cmake/cmake-3.22.5-windows-x64.zip external/windows/cmake/cmake-3.22.6-windows-x64.zip 
@mmitche
Copy link
Member

mmitche commented Jun 10, 2024

I think a switch may have been dropped in the repo merge. It looks like the installer repo was using -nativeToolsOnMachine (which repos were supposed to migrate to). I think this supports "latest"

@directhex directhex closed this Jul 16, 2024
@akoeplinger akoeplinger deleted the directhex-patch-1 branch July 17, 2024 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Infrastructure untriaged Request triage from a team member

6 participants