Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Infer dapr.yaml when omitted from configuration #284

Closed
philliphoff opened this issue Feb 10, 2023 · 6 comments
Closed

[Enhancement] Infer dapr.yaml when omitted from configuration #284

philliphoff opened this issue Feb 10, 2023 · 6 comments
Assignees
Labels
enhancement Update to existing feature

Comments

@philliphoff
Copy link
Collaborator

If a Dapr task definition or debug launch configuration has been defined without an explicit run file, infer the dapr.yaml at the root of the workspace (if present). This will make creation/scaffolding of such configuration files simpler.

@philliphoff philliphoff added the enhancement Update to existing feature label Feb 10, 2023
@IvanJobs
Copy link
Collaborator

@MregXN You can investigate on this one first.

@MregXN
Copy link
Contributor

MregXN commented May 12, 2023

Hi, @philliphoff. Is that mean the local dapr.yaml file should be read by this extension and properties in this file needs to be filled in task.json and launch.json?

@philliphoff
Copy link
Collaborator Author

No, the suggestion is that, if the tasks.json and launch.json files omit the property that would normally point to the one and only dapr.yaml in the repo, the extension, when running the task and/or launching the debugger would simply assume that that dapr.yaml is the one to be used in the dapr run -f ... command. The .json files need not be changed. We're just saying that the user doesn't need to tell the extension (in the .json files) which file to use because the extension can figure it out at the time it actually needs to use it.

@MregXN
Copy link
Contributor

MregXN commented Jun 11, 2023

Hi, @philliphoff. I wanna confirm my understanding is correct with following code snippet.

tasks.json:

      {
          "label": "dapr",
          "type": "dapr",
         // "runFile": "./dapr.yaml"
      }

launch.json:

      {
          "name": "Launch Dapr",
          "request": "launch",
          "type": "dapr",
          //"runFile": "${workspaceFolder}/dapr.yaml",
          "preLaunchTask": "dapr"
      }

If users do not specify a runFile (e.g., it is commented out in the code snippet), but task and launch configurations of type "dapr" still exist, extension should automatically use the dapr.yaml in the workspace without modifying these two json files. Is this right?

@philliphoff
Copy link
Collaborator Author

If users do not specify a runFile (e.g., it is commented out in the code snippet), but task and launch configurations of type "dapr" still exist, extension should automatically use the dapr.yaml in the workspace without modifying these two json files. Is this right?

Correct, there is no need to modify the configuration files; the extension should just assume use of the run file in the workspace (when it actually invokes the task/launch).

Thinking about this more, there may be a subtlety here in that we should probably make this assumption only when no other properties are specified.

For example, make the assumption in this case (because there's no properties that would otherwise be placed in a run file):

{
  "dapr": "dapr",
  "type": "dapr"
}

But not in this case (because the app ID is specified, indicating an explicit configuration of an app)

{
  "dapr": "dapr",
  "type": "dapr",
  "appId": "my-app"
}

@philliphoff
Copy link
Collaborator Author

Closed with #300.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Update to existing feature
Projects
None yet
Development

No branches or pull requests

3 participants