Open scottiedog45 opened 1 year ago
hi @scottiedog45 - I see you are using a Go application. Did you enable go modules
support for your project? This is required for debugging Go containers with Cloud Code IntelliJ.
From that link:
To configure your application for debugging, your app must be a Go Module-based application and be identified as being Go-based by setting one of the standard Go runtime environment variables in the container, such as GODEBUG, GOGC, GOMAXPROCS, or GOTRACEBACK. GOTRACEBACK=single is the default setting for Go and GOTRACEBACK=all is a generally useful configuration.
To enable Go modules, go to Settings > Languages & Frameworks > Go > Go Modules, and select Enable Go modules integration
:
Hey @etanshaul , thanks for the speedy reply.
Can confirm modules are enabled:
Also on Go version 1.19.4 if that helps. Also, I'm using Goland, specifically.
I see. I am not able to reproduce with the go-guestbook application.
Are you able to see the debug tabs as shown here:
Also, just in case (I've made this mistake before) - where did you set your breakpoint? You won't be able to debug the server start up code as-is (main()
) as the debugger is attached later. Instead, try setting a breakpoint in the homeHandler
:
Otherwise, is there anything you may have changed in your application?
Yep I can see the debug tabs, but there is no output when the application starts:
I made a fresh project, just to be sure I haven't changed anything. Still seeing the same output. Not sure if these lines from the terminal output are suspicious:
Some taggers failed. Rerun with -vdebug for errors.
[frontend] 2023-01-09T15:37:34Z error layer=rpc writing response:write tcp 127.0.0.1:56268->127.0.0.1:34416: use of closed network connection
[backend] 2023-01-09T15:37:34Z error layer=rpc writing response:write tcp 127.0.0.1:56268->127.0.0.1:34418: use of closed network connection
Made sure to put a breakpoint in the homeHandler, still not being hit.
fwiw, the console
tab is also blank for me, and I also see the following messages in the verbose logs:
[frontend] 2023-01-09T16:39:31Z error layer=rpc writing response:write tcp 127.0.0.1:56268->127.0.0.1:51758: use of closed network connection [backend] 2023-01-09T16:39:31Z error layer=rpc writing response:write tcp 127.0.0.1:56268->127.0.0.1:48174: use of closed network connection
Yet, I can still hit the breakpoints.
You should be able to get a bunch of additional debug logs if you enable verbose debugging on Skaffold. To do this, in the Run Configuration, under advanced settings
, set logging verbosity
to DEBUG
:
If you search for the keyword "debug" in the log, you should see several bits on information. For example this snippet showing successful application of the debug transformations:
Configuring "" for Go/Delve debugging
"frontend" requires debugging support image "go"
Configuring installation of debugging support files
Applied debugging transform:
apiVersion: apps/v1
kind: Deployment
here is a gist containing my debug level logs for the go-guestbook app (with working breakpoint debugging), in case it helps for comparison.: https://gist.github.com/etanshaul/4d27a3244e17b0ad68d16d9f143e0553
If you share yours, I can take a look too
Thanks again for your help with this, and easing my mind about those logs before.
Here is a link to my gist of logs.
One difference I can see is regarding tags. Yours says
Tags used in deployment:
- go-guestbook-frontend -> gcr.io/etan-gcp/go-guestbook-frontend:v2.0.1-1-gaa0bf348b-dirty@sha256:4186360accc42b675ca32aeb216d4a78881d2486e0d929d1b7d608115cc89f60
- go-guestbook-backend -> gcr.io/etan-gcp/go-guestbook-backend:v2.0.1-1-gaa0bf348b-dirty@sha256:e9b59ccc2d56c0a8532175e888df09a23aacadb3ecdd4dbfed365d2f46acdd5c
push value not present in isImageLocal(), defaulting to true because cluster.PushImages is true
push value not present in isImageLocal(), defaulting to true because cluster.PushImages is true
while mine is
Tags used in deployment:
- go-guestbook-frontend -> go-guestbook-frontend:3d6a7afe103cef8afbc064da54b654c69ceabbac8d1ee73d53b94038e94f8e35
- go-guestbook-backend -> go-guestbook-backend:09130c2d49256a3c65c898d5fcdd90315874ea2a009c9b33ad1c8d1f93aa7c99
push value not present in isImageLocal(), defaulting to false because cluster.PushImages is false
push value not present in isImageLocal(), defaulting to false because cluster.PushImages is false
Local images can't be referenced by digest.
They are tagged and referenced by a unique, local only, tag instead.
See https://skaffold.dev/docs/pipeline-stages/taggers/#how-tagging-works
Here is a copy of my rc, to verify that I'm trying to deploy to a local cluster
strange. The only other difference I noticed here is that you are deploying to a minikube cluster (whereas I was using GKE). I tried minikube however, and it worked fine, so this is a bit perplexing.
I will give the logs another closer look and see if we have any ideas.
In the meantime - could you try the simple hello-world Go app (not the guestbook app)? It is in the New Project wizard as well. I wonder if it is that app specifically.
I can hit breakpoints in the hello-world app 🥳 .
I tried the guest book app after again, and noticed that several debugger tabs open instead of two (i.e. one for the backend and frontend). This time, two were opened for the front end? Also, the breakpoints shift to an "invalid" state when the front end tabs are selected, even though the breakpoints are in the frontend:
(Please ensure you are running the latest version of Cloud Cloud IntelliJ with Help > Check for Updates.)
(screenshots are often helpful)
Expected Behavior
Normal breakpoint behavior when running debug mode, like pausing at breakpoints.
Actual Behavior
Breakpoints skipped/not hit
Additional Information
Trying to run the guestbook application. I can see the output in the terminal indicating there might be a problem connecting with the debugger. Everything else in the project seems to work fine when running outside debug mode.
I am able to hit breakpoints when running the project through VS Code.
Feel free to deviate from this template as needed, especially if you are submitting a feature request.
Here is the full log if it's helpful: