VS2019 Professional is missing the "Start Debugging" action item which is preventing me from debugging within my docker container.
I have created a launchSettings.json file to explicitly set the StartDebugging action, but still it is omitted from the profile and the debugger does not get attached when attempting to run in debug mode.
{
"profiles": {
"Docker Compose": {
"commandName": "DockerCompose",
"serviceActions": {
"data": "StartDebugging",
"api": "StartDebugging",
"graphql": "StartDebugging",
"kafka": "StartWithoutDebugging"
},
"commandVersion": "1.0"
}
}
}
Another member on the team has the same IDE version as I do, but has no issues having the debugger attached when running in debug mode. We have compared our VS2019 installations and confirmed that we have same workloads installed as well, yet his has the option.
Why would the "Start Debugging" action be missing and how do I bring it back?
I was having the same problem and saw this thread: docker compose doesn't work debugging. The workaround worked for me: disable Docker-Compose V2 support by running docker-compose disable-v2 and then restart Docker Desktop. This is apparently caused by the recent change in docker compose v2 behavior; see Output of "docker compose config" does not contain full path to context
Related
In my node project, I would like to define a script in my package.json file like:
{
"scripts": {
"runTestsWithTilt": "<some command to run tests within a container launched by tilt>"
}
}
Is there a tilt cli command where I could run an arbitrary command through docker exec?
Something like: tilt docker exec <container-name> <command-to-run>
Tilt is still developing and the documentation is very minimal, in the official documentation and in the official github page they have mentioned only a syntax for executing docker commands but they didn’t provide a complete manual anywhere. So for now, similar to KinD (Kubernetes in Docker) we need to use docker commands for a few operations. Hope this will be addressed soon.
I have a Docker container with MongoDB, with a /docker-entrypoint-initdb.d/... script with my initial mongo config.
The problem is that it doesn't get executed when run by Jenkins (through docker-compose up via SSH). When I start the container "manually" (same command through console, also SSH) - all is fine.
I'm a newbie at Jenkins, I think that's the case - the Jenkins SSH agent ceates a workspace that differs from the dir that Docker uses when run by me through terminal. But all the required files are there.. maybe it has sth to do with the script being executed only on initial startup? I tried removing it from the agent's workspace to be initialized again, but still no luck..
I have VS Code running on macOS connecting to a linux box where I am doing Go development. I am connecting via a user that has sudo privileges on the linux host. The root account is disabled on the remote host.
The application I am writing needs to run with root privileges. Is there a way to set vscode to elevate privileges when debugging the application? Or do I need to enable the root account for software development purposes?
While not the exact same environment, I suppose that the needed underlying functionality of needing root to debug, test, and run your code from VSCode is the same as in this answer to How can I debug Go file in VS Code with root privileges? here.
The gist: VSCode version 1.65.0 has a new experimental launch option "asRoot": "true", use it with "console": "integratedTerminal".
For instance, in your launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Test/dbg pkg as root",
"type": "go",
"request": "launch",
"mode": "test",
"program": "${fileDirname}",
"console": "integratedTerminal",
"asRoot": true,
},
]
}
When launching this configuration by pressing F5, a new debug terminal session opens (or might get reused) and the following command executed, needing sudo (which you mentioned you do have rights to use):
/usr/bin/env GOPATH=/home/foobar/go /usr/bin/sudo /home/foobar/go/bin/dlv dap --check-go-version=false --client-addr=:41945
Here is how I was able to run my tests as root for Python development. This should work for most Visual Studio Code debug environments. First run the debugger and let the Debug Console start up. Stop debugger if needed. Run sudo su and enter password. Now the Debug Console is running as root.
It appears that when using the Restart debugger command, it creates a new console so this cannot be used; you need to stop and than restart.
Start debugging again and you should now be root.
If you close the debug console, you will need to repeat the above steps.
Below is the answer I received from the vs code developer team. This isn’t a feature and it will never be a feature.
In order to debug as a root, the debugger (dlv) must run as a root.
Nether dlv, nor this extension aims to offer privilege escalation
solutions. In remote debugging, dlv on the remote machine is
externally managed, not by this extension, so it's out of scope.
Moreover, this extension just communicates with the dlv on the remote
host with DAP, which is not designed for security. So I am afraid this
extension is not the right layer for privilege escalation. To debug as
a root, as you already know, run dlv on the remote machine as a root
(you may also need to set --only-same-user=false if the remote host is
Linux) but protect access to the dlv server & the remote machine
appropriately using proven security technologies. For local debugging,
this is tracked in #558. But, I want to emphasize that debugging as a
root still needs to be done with great care.
I need to code / edit files in a remote server using SSH, and I would like to access it with VSCode.
I'm on Windows 10, using "Git Bash" as integrated terminal in VSCode, which means I can connect to the server using VSCode's terminal.
What I'm missing is a way to open files from the terminal to the editor, and even better - interacting with the files using the explorer.
How can this be done?
Since the May, 2nd 2019 announcement of "Remote Development with VS Code", you now officially have:
Visual Studio Code Remote - SSH
The Remote - SSH extension lets you use any remote machine with a SSH server as your development environment.
Since nearly every desktop and server operating system has a SSH server that can be configured, the extension can greatly simplify development and troubleshooting in a wide variety of situations.
You can:
Develop on the same operating system you deploy to or use larger, faster, or more specialized hardware than your local machine.
Quickly swap between different, remote development environments and safely make updates without worrying about impacting your local machine.
Access an existing development environment from multiple machines or locations.
Debug an application running somewhere else such as a customer site or in the cloud.
Q1 2020: VSCode 1.42 improves support for Windows servers, including automatic OS detection.
Is this what you are looking for?
https://marketplace.visualstudio.com/items?itemName=humy2833.ftp-simple#overview
You need to setup sFtp connection to your server.
Install extensions Code Runner and SSH-FS. Add config into your user setting like this:
"code-runner.runInTerminal":true,
"code-runner.fileDirectoryAsCwd": true,
"code-runner.ignoreSelection": true,
"code-runner.saveFileBeforeRun": true,
"files.eol": "\n",
"sshfs.configs": [
{
"label": "label",
//Must use the root direction "/"
"root": "/",
"host": "host",
"port": port,
"username": "name",
"password": "password"
"name": "name"
}]
Login your server account over ssh by the vscode terminal. Then you can edit and run your code on remote server.
Try disabling it and re-enabling it. It works for me.
I was able to log in via putty and ssh from terminal, so it wasn't that. It's just the configuration gets hung up or something.
All of the previous answers require installing a package from the VS Code Marketplace. Here is a solution, that won't even require you to install VS Code.
The Web Based VS Code Editor: Run VS Code on any machine anywhere and access it in the browser.
All you need to do is, first install code-server using:
$ curl -fsSL https://code-server.dev/install.sh | sh
Start code-server using:
$ code-server
After running this you can log on to https://127.0.0.1:8080 and view the web-based VS code.
To keep the service running in the background, use:
$ sudo systemctl restart code-server#$USER
You might also want to edit the configurations, for e.g., run it on 0.0.0.0:8080 instead of 127.0.0.1:8080 or to change the password - use:
$ nano ~/.config/code-server/config.yaml
I have used nano as my text editor, feel free to use your preferred text editor.
For in-depth setup and configuration guide: Setup Guide
Original GitHub repo for more info: code-server
When I start my app using 'npm start' at the command line I can browse it at :3000
.. but not when I start it using 'node app.js'
when I try 'node --debug app.js' I get a console window with the message
"Debugger listening on port 5858"
With Visual Studio and the node toolkit I get the same. With Eclipse and Enide I get the same.
I've tried using Nodes built in command line debugger, but after the debug> prompt appears issuing the continue or next step commands does nothing, and I can't browse the app at :3000
I've installed node-inspector, and after 'node --debug app.js' I can see app.js in the node-inspector chrome tab :8080, but can't browse my app at :3000 and can't get breakpoints to work.
I guess that to get debugging working I need 'node app.js' to run, and not be using 'npm start'..
What important node configuration detail have I missed?
Why is my app not browsable when using 'node app.js' ?
Any advice is appreciated..
Your actually starting the app in two differnet ways using different code - one which includes the debugger and one that does not.
If your running a default Express 4 setup, if you check the package.json file you will see this section:
"scripts": {
"start": "node ./bin/www"
}
That is the file that is executed when you run npm start, so running node app.js is actually a different script.
If you take a look at bin/www you will see the debugger is invoked:
var debug = require('debug')('myapp');
To run use:
DEBUG=myapp ./bin/www
If you are starting using NPM, you can add it to the package.json or use exactly the same command from the cmd line:
"scripts": {
"start": "DEBUG=myapp node ./bin/www"
}