dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.87k stars 463 forks source link

Run Resource Commands from Console Logs Page #6626

Open afscrome opened 1 week ago

afscrome commented 1 week ago

Is there an existing issue for this?

Is your feature request related to a problem? Please describe the problem.

I've been doing some iteration of onboarding some db migrations into Aspire, which has involved me

  1. Go to Dashboard
  2. Go to Console Logs
  3. See Error and tweak migrations scripts to fix
  4. Go back to the Dashboard to restart the resource
  5. Go back to Console Logs to see why the process errored this time

As I'm able to iterate on the migrations outside of aspire, I can test changes by simply restarting the migration resoruce, rather than rebuilding the whole app host.

Describe the solution you'd like

I'd like the ability to be able to start / stop and restart a resource (and potentially any other resource command) directly from the Console Logs page, without having to go back to to the dashboard and then back to console logs. That way I could stay on the console log page the entire time - view errors, fix them then restart the migrations from within the console logs page.

Something like: Image

Additional context

No response

malisancube commented 1 day ago

Very nice idea.

  1. I've needed the ability to export the logs/traces. This would help in various instances including reporting, rather than using screenshots for traces.

  2. Additionally if there is Commands that can be used on multiple Resources at the same time.

  3. Adding a way to notify on custom thresholds/conditions that can be added as filters.

joperezr commented 1 day ago

Would this only be applicable to console logs? @drewnoakes mentioned during triage that we may want to consider putting this in other telemetry places.

afscrome commented 22 hours ago

Yes, would definitely make sense in other telemetry place where the telemetry is scoped to a single resource. (i.e. it may not make as much sense in a trace crossing several different resources, unless it is clear which resource the commands apply to)