Is something wrong with my VSCode "attach remote" configuration? I can do command-line debugging with dlv connect :2345 and actually debug the remote process just fine, which indicates the headless server is functional. I send that request, I get a result, and that breakpoint never hit, indicating that I haven't yet achieved remote debugging. I have one breakpoint defined which I know would be hit by a request I can send the remote process. It isn't crystal clear, but that UI leads me to believe I'm now connected to the remote headless debugger and ready to debug. Upon starting the "attach remote" VSCode debugging configuration I get In VSCode I define launch.json as follows: The process is started in the docker's entry point viaĭlv debug /go/src/path/to/package -headless -listen=:2345 -log for the purpose of enabling debugging later in VSCode.ĭocker run -rm -it -p 2345:2345 my_image:tag. And before that - unit testing is my best friend.I run a process inside a docker container that needs to be debugged. So I’ll wait when Goland natively supports go1.x with its AWS Toolkit plugin. And if I need a real lambda running, I just run the lambda locally:) For me easier is to run a unit test and invoke the desired handler directly. I spent some time playing around and running all that magic, and seems that it is for true geeks only. Trying to run the SAM locally and attaching to the debugger works, but doesn’t hit the breakpont. So the Goland itself uses the remote debugging described in AWS guide. Go test run config sets working dir to project dir instead test directory in 2021.1 Beta. Run targets: Path to Go is shown instead instead of version. "/Users/username/Library/Application Support/JetBrains/Toolbox/apps/Goland/ch-0/202.7319.61/GoLand.app/Contents/plugins/go/lib/dlv/mac/dlv" -listen=0.0.0.0:50909 -headless=true -api-version=2 -check-go-version=false -only-same-user=false exec /private/var/folders/b7/dtfbb67x1sxgmcm490vtt8rm0000gn/T/_go_build - So the Goland itself uses the remote debugging described in AWS guide. (run tool) console shows no output when running program with sudo. Starting a debug session will give something like this: /usr/local/Cellar/go/1.15.2/libexec/bin/go build -o /private/var/folders/b7/dtfbb67x1sxgmcm490vtt8rm0000gn/T/_go_build -gcflags all=-N -l hello-world #gosetup After you open the project in Goland you’ll notice the green triangle next to func main(). Lets generate a new app by running sam init and selecting go1.x and Hello-World template. But, regarding the debugging in Goland, it means, that you already have everything installed. The guide suggests installing delve debugger, then run some commands.
#GOLAND REMOTE DEBUG CODE#
One may say that this is not a true “go way”, but I still remember the times, when there was no debugger for go at all, and debug was possible by adding some library to the project and inserting debug instructions to the code itself, which is weird in 2020. Currently I managed to do a debug by running unit tests that run the handlers. Maybe it changes one day and this article become obsolete, who knows. Currently Goland IDE does not support debugging for go lambdas natively. And now we are back to the programming basics - debugging for go lambdas.
0 kommentar(er)
