You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dapr 1.10 adds "run flies", a way to run Dapr applications both as a group as well as to consolidate configuration (e.g. ports, component paths, etc.). Much like with Tye, run files enable a simpler way to get applications running than using the current Dapr task/config scaffolding.
If a workspace folder already has a Dapr run file when scaffolding Dapr tasks, those tasks should use the run file.
I think more discussion might be needed to determine, if no run file is present, weather a run file should be scaffolded as well as a task to use it. That's probably the case, but perhaps that's going too "all in" on run files for the moment.
The text was updated successfully, but these errors were encountered:
Hi @philliphoff,
I want to confirm if my understanding is correct. If the work space already has a "dapr.yaml" file, the using "Dapr: Scaffolding Dapr Tasks" command will generate the following task and configuration.
tasks.json:
@yukun-dong Yes, I think that's what we should do. (I think we'd also want to use ${workspaceFolder}/dapr.yaml in the task as well as the configuration.)
Dapr 1.10 adds "run flies", a way to run Dapr applications both as a group as well as to consolidate configuration (e.g. ports, component paths, etc.). Much like with Tye, run files enable a simpler way to get applications running than using the current Dapr task/config scaffolding.
If a workspace folder already has a Dapr run file when scaffolding Dapr tasks, those tasks should use the run file.
The text was updated successfully, but these errors were encountered: