search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.66k stars 1.06k forks source link

`dotnet workload list --machine-readable` prints workload update messages to stdout #37161

Open baronfel opened 9 months ago

baronfel commented 9 months ago

Describe the bug

dotnet workload list --machine-readable always emits manifest update messages to stdout. This means that the machine-readable output cannot be simply parsed by taking stdout.

To Reproduce

$ dotnet workload list --machine-readable
Skipping NuGet package signature verification.
Updated advertising manifest microsoft.net.workload.emscripten.net7.
Updated advertising manifest microsoft.net.sdk.maui.
Updated advertising manifest microsoft.net.sdk.android.
Updated advertising manifest microsoft.net.sdk.macos.
Updated advertising manifest microsoft.net.workload.emscripten.net6.
Updated advertising manifest microsoft.net.workload.emscripten.current.
Updated advertising manifest microsoft.net.sdk.tvos.
Updated advertising manifest microsoft.net.sdk.ios.
Updated advertising manifest microsoft.net.sdk.maccatalyst.
Updated advertising manifest microsoft.net.workload.mono.toolchain.net6.
Updated advertising manifest microsoft.net.sdk.aspire.
Updated advertising manifest microsoft.net.workload.mono.toolchain.current.
Updated advertising manifest microsoft.net.workload.mono.toolchain.net7.
==workloadListJsonOutputStart==
{"installed":["wasm-tools"],"updateAvailable":[]}
==workloadListJsonOutputEnd==

This is because the workload updater used for the list command here doesn't set the optional bool displayManifestUpdates = true constructor parameter.

We should make that parameter available to list and flow it through to the updater here. This is another one of those 'stop logging diagnostic messages to stdout' issues.

Further technical details

MiYanni commented 9 months ago

So, Chet and I talked a bit about this offline. This was already fixed in main here: https://github.com/dotnet/sdk/pull/35640 We were deciding if it needs to be backported at this point or not. Keep in mind, it is a breaking change since tooling parsing for anyone using this would need to be changed.

baronfel commented 9 months ago

I think we should given that partner teams want to use this to automate.