We should have the option to reset the initial prompt that generate tasks.json

Is your feature request related to a problem? Please describe. When I want to Debug (Local Tunel) into another container; I have to update tasks.json. I wasn't able to find a way to reset the file completely so that I can go through the prompt again. Deleting the file tasks.json doesn't reset the prompt.

Describe the solution you'd like

There should be an option to always have the option to get the prompt that will generate the tasks.yml file

Describe alternatives you've considered

Alternatively I should be able to reset tasks.json to default ( in case I made a mistake )
Or the system should be smart enough to know when I'm switching between pod.

Additional context

Thanks for opening this issue! You can force Bridge to show again the prompt by deleting the debug configuration we add in your .vscode/launch.json file ("XYZ with Kubernetes"). Once you delete it, when you select Debug (Local Tunnel) on a pod, you'll be asked to configure the connection.

I agree that the user experience with this flow isn't great. The assumption made was that users would open a specific folder in VS Code for each of their pods/services, and that that way you could configure each of them separately. I'm opening a bug on our side to revisit this scenario and see how we can improve it.

Something else that I wanted to mention is that if the pods you debug correspond to a Kubernetes service, you might consider configuring the Bridge connection directly for the whole service and not at the pod level. That way, you'll be able to:

Reconfigure easily your Bridge connection by using the "Bridge to Kubernetes: Configure" command:
Enable the isolation option (allows multiple developers to share the same cluster, by making sure that the traffic from each is only redirected to their machine while debugging).

To start Bridge after the configuration, you can use the Debug (Local Tunnel) option from the Kubernetes extension in Network > Services:

You can also just run the debug profile we create for you when you configure (also created when debugging pods):

Please don't hesitate if you have any questions!

Thanks for this.

Should I empty the content of the "configuration" option array? or should I remove the definition of "configuration" all together?
How/when is "preLaunchTask": "bridge-to-kubernetes.resource" added?
What's the difference between "Debug (Local Tunel)" and "Debug Attach" and "Attach Visual Code"

@richardsondx Sorry for not replying earlier, the day has been busy with the other issues!

Please remove only the configuration that Bridge to Kubernetes created:

To give a bit more context, when you configure Bridge we ask you for a launch configuration to use to run your code locally: The configurations listed there are the ones declared already in your .vscode/launch.json file, and that you can use to debug your code locally.

We then duplicate this configuration in launch.json and add our connection preLaunchTask in it (bridge-to-kubernetes.resource or bridge-to-kubernetes.compound). That way, when you start this launch configuration from VS Code's debug panel, we first connect (through the preLaunchTask) and then execute the configuration to run your project locally.

We create our task(s) in tasks.json and the new launch configuration in launch.json when you configure Bridge (Bridge to Kubernetes: Configure command, or when debugging for the first time a pod).
Bridge to Kubernetes handles the "Debug (Local Tunnel)" option (actually, we're one of the implementation but technically another extension could handle this option as well), but the other debugging options are managed by other VS Code extensions. As such, I don't have a lot of info about them. If I remember correctly, the Debug (Attach) option is provided by the VS Code Kubernetes extension and provides a remote debugging option (deploy your changes to the cluster and attach a debugger), which is different compared to the hybrid approach taken by Bridge (redirect the cluster traffic to your dev machine and debug from there). You should be able to find more information in their documentation if you're interested in it: https://github.com/Azure/vscode-kubernetes-tools/blob/master/debug-on-kubernetes.md

Thanks! As always your response are very helpful!

The port tunnelling didn't end up working for me. When I would redirect the pod to 3000 I wasn't able to access it at localhost:3000 and/or debug. I ended up setting 0 instead but it seem that the debugger wasn't running in any context. I think there are a couple issues involved that are not necessarily related to this extension:

One of these issue is having the right configuration for launch.json.Setting the launch.json correctly for my already running pod ( which made me wonder if Kubernetes extension Deploy (Attach) made more sense to use since it connect sto an already running pod; while launch run something before connecting to the pod. I play around with setting launch.json but everytime it wouldn't allow me to load the pod. The pod I'm trying to access are already running in a staging environment – I don't need to run the server since its already running but leaving the configuration empty doesn't work. Can the bridge just attach to that?
With a complex system like the one I'm dealing with (especially if you're using fastly and already a bunch of port forwarding) the port forwarding might not work when I set a value. When I set it to 0 I was able to copy the IP_ADDRESS + PORT provided in the terminal for each pod services to view them on my browser; but still, I wasn't able to debug within my pod. It just couldn't access the service on the browser when I was trying to access localhost:port
It wasn't very clear how to launch specific command with the Configuration. Based on the documentation; It uses program to launch the binary file for /bin/rails but then if I need to pass bundle exec before running the rails command; it's not clear where to add that. Removing program and just passing argument won't do it. There's a lot of things to learn or get familiar with here that are not necessarily related to the extension but VS code Debugging tool that I'm not familiar with. The expectation when you install the plugin is that it would just connect similarly to the Visual Code Docker Extension or Lens where most of the work is done behind the scene.
When the extension redirect the traffic to my local environment doest hat mean that if I use the remote service at its original address; that the debugger will still step in where the breakpoint is set? One issue I ran into when the pod was tunnelled to my local was the Cross Browser request complains from my browser when I was attempting to login. Since the request is local but the service has a remote address; the browser was complaining. From my understanding the service is intended to run a full remote environment locally (in my case staging server) so I wanted to confirm the functionality of that traffic redirection.

Thanks a million.

Thanks for your message! And glad that my comments are helpful.

Using a remote debugger such as Debug (Attach) is indeed an option, but it also comes with its share of challenges (language specific approach, and slower than our hybrid approach). We actually built Bridge because we believe that it's a better approach to debugging compared to remote debugging, so I'm obviously a bit biased. :)

If you decide to use Bridge, the first suggestion I would have is that we need to make sure that you can run your code locally, independently of Bridge. I'm not familiar with Ruby on Rails, but there are some articles online that might help you configure a launch.json in VS Code for your app: https://andyv.me/til/debug-a-ruby-on-rails-server-using-vs-code/

Alternatively, if you're able to run your app locally independently of VS Code (in a command prompt, in another IDE...), we can also work with that! When configuring Bridge to Kubernetes, you can always choose "Configure Bridge to Kubernetes without a launch configuration":

If you select this option and configure Bridge without a launch configuration, then you will need to:

Make sure that you have our task generated properly in the .vscode/tasks.json file with the right parameters.
Click on our status bar menu:
Start the connection from there:
Once connected to the cluster, run your app separately (in a command prompt, another IDE, etc.)

When we redirect the cluster to your machine, we do it at the machine level (updating the /hosts file). This is why a command prompt/another IDE can also use the replicated services we create from VS Code.

If your app listens locally on port 3000, then this is what you should use when configuring Bridge to Kubernetes. If you specify 0, then we won't redirect traffic from your cluster to your machine. I also confirm that you shouldn't use your localhost address once you're connected with Bridge: as we redirect the traffic from your cluster, you can just use the usual entry point you use to access your cluster. When the traffic reaches the service you redirected to your machine, we will forward it to your dev machine and to the port you configured (3000 here) so that your app running locally receives it. Please note that trying to access localhost:3000 is still a good experiment to validate that your service is actually running locally properly. If you can't get a response from this, then most likely your launch configuration didn't work fine.

I hope I answered your questions, but please don't hesitate if something isn't clear or I missed something. Also, I'm happy to get on a call and have a look at your configuration if it helps!

microsoft / mindaro

We should have the option to reset the initial prompt that generate tasks.json #199