Integrate DTS emulator with workspace view

[philliphoff]

Adds a DTS emulator node to the Workspace view of the Azure Resources explorer, which will show running DTS emulator instances. This node offers the ability to start new emulator instances. Emulator nodes, like in the Azure Resources view, offers the abilities:

• Copy connections strings
• Open the corresponding task hub dashboard
• Shutdown the emulator

The DTS settings have been updated to allow customization (i.e. registry, image, tag) of the emulator container image. Emulators started by the VS Code instance will be shutdown when the instance is closed. (Emulators started outside of the VS Code instance will not be shutdown.)

Note: the emulator features are not hidden behind the "preview features" toggle as they are (as of now) available to all.

[nturinski]

Phil, would it be possible to add a command to install/uninstall the emulator similar to Azure Functions Core Tools?

When you activate the extension, it immediately throws an error as well:

I think that it may be a jarring experience for users that do not have the DTS emulator installed or are not engaging with it.

[philliphoff]

@nturinski Thanks for taking a look.

Phil, would it be possible to add a command to install/uninstall the emulator similar to Azure Functions Core Tools?

The emulator is just a Docker container; there's nothing to install or uninstall really (save pulling/removing an image). I'll think about whether we can show/hide the workspace node based on the existence of the image (and then have a command that just pulls it). I feel that's not terribly discoverable, though.

When you activate the extension, it immediately throws an error as well:

Well that's not good; I'll try to repro and resolve that.

[nturinski]

The emulator is just a Docker container; there's nothing to install or uninstall really (save pulling/removing an image). I'll think about whether we can show/hide the workspace node based on the existence of the image (and then have a command that just pulls it). I feel that's not terribly discoverable, though.

I think if the node could instruct users on where/how to get the image, that could be helpful. Like a disabled/enabled state? That way we could still have the discoverability regardless.

[philliphoff]

I think if the node could instruct users on where/how to get the image, that could be helpful. Like a disabled/enabled state? That way we could still have the discoverability regardless.

@nturinski The image will be auto-pulled if/when the user attempts to start the container, so there's nothing they need to do (aside from Docker being running).

That said, I've added some robustness to the Docker management logic, and on errors the DTS Emulators node will show a warning node with the error (e.g. "is Docker installed and running?"). I've also updated the root node to auto-expand only if emulators are already running. This should make the feature a little less "in your face" if you're not actually using it.

[alexweininger]

Would you want to try to start the Docker runtime for the user if it's not already running? I know there are other runtimes, but I think most devs still use Docker. Mostly suggesting it because I was using the dev containers feature in VS Code today and it auto started Docker desktop for me so it's fresh in my mind.

[alexweininger]

Non-blocking feedback here:

Since there aren't that many actions available on the emulator tree item and the task hub item, I think it makes sense to expose the "big" ones as buttons on the tree item itself. Similar to the buttons we have on the Functions local project tree item:

I think at least a stop/start button on the emulator item would make a lot of sense. And an open in dashboard button on the task hub. I figure we might as well make these things as discoverable as possible.

[philliphoff]

Would you want to try to start the Docker runtime for the user if it's not already running? I know there are other runtimes, but I think most devs still use Docker. Mostly suggesting it because I was using the dev containers feature in VS Code today and it auto started Docker desktop for me so it's fresh in my mind.

@alexweininger I talked to the Docker extension team and they, themselves, do not automatically start the container runtime so I'm hesitant to try to do that in this case. (Just trying to understand which runtime is in use and how to start it would be a significant concern--I'm using the Docker extension client library to abstract away the runtime being used, so the extension doesn't actually know.)

[philliphoff]

I think at least a stop/start button on the emulator item would make a lot of sense. And an open in dashboard button on the task hub. I figure we might as well make these things as discoverable as possible.

@alexweininger Those are good ideas and I've added inline commands for opening the taskhub dashboard, as well as for starting and stopping emulator instances.

[philliphoff]

@alexweininger Bump. (Not in any hurry, just don't want to forget about it myself.)

[nturinski]

There were a couple of times get children returned an empty array or the context values were joined with a space. I didn't feel like I needed to comment on every single one, but if you'd like me to just so it's easier to identify where those all are, I can do that.

[nturinski]

Overall looks good to me. Let me know whenever you're done-- any approval I do now is just going to get stale.

[nturinski]

@philliphoff I'm going to hold off on merging this for just a couple of days. We had CTI run a release test pass this week and we were planning to release today or Monday.

We'll release again soon including this and other DTS changes.

[philliphoff]

No worries! Thanks for taking the time to review!