Use 'aspire logs' command for viewing resource logs in extension#15094
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15094Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15094" |
There was a problem hiding this comment.
Pull request overview
Updates the VS Code Aspire extension’s “View Logs” action to use the new top-level aspire logs CLI command (instead of routing through aspire resource <name> logs), aligning the extension with the updated CLI command shape.
Changes:
- Switch “View Logs” to run
aspire logs "<resource>" --apphost "<path>" --follow. - Resolve the correct AppHost for the selected resource before issuing the logs command.
You can also share your feedback on Copilot code review. Take the survey.
| const appHost = this._findAppHostForResource(element); | ||
| if (!appHost) { | ||
| return; | ||
| } | ||
| this._terminalProvider.sendAspireCommandToAspireTerminal(`logs "${element.resource.name}" --apphost "${appHost.appHostPath}" --follow`); |
There was a problem hiding this comment.
sendAspireCommandToAspireTerminal supports an additionalArgs array with platform-specific quoting/escaping, but this code builds a single interpolated command string with manual double-quoting. If resource names/paths ever contain characters like quotes, $, or backticks, this may not behave consistently across shells. Consider switching to sendAspireCommandToAspireTerminal('logs', ..., additionalArgs) (passing the resource name, --apphost, path, and --follow as separate args) and optionally making this method async/awaiting the call for clearer error propagation.
| if (!appHost) { | ||
| return; | ||
| } | ||
| this._terminalProvider.sendAspireCommandToAspireTerminal(`logs "${element.resource.name}" --apphost "${appHost.appHostPath}" --follow`); |
There was a problem hiding this comment.
This change updates the exact CLI command shape used for the "View Logs" action, but there’s no unit test asserting the constructed command. Consider adding a small test that mocks AspireTerminalProvider and verifies the logs <resource> --apphost <path> --follow invocation to prevent regressions when CLI command shapes change again.
Description
The
aspire logscommand was introduced as a top-level CLI command (instead ofaspire resource <name> logs). This PR updates the VS Code extension's "View Logs" tree action to use the newaspire logs "<resource>" --apphost "<path>" --followcommand shape instead of routing through theresourcesubcommand.Checklist
<remarks />and<code />elements on your triple slash comments?aspire.devissue: