#Tilt-like workflows thread, let's roll
1 messages · Page 1 of 1 (latest)
How might I wire a debugger into said container under this approach?
Consider our example earlier. DaggerSession1 runs the kube process. DaggerSession2 is a golang app, that is my app, let's call it ToDoListApp. I want a local dev experience that is kube-first. I run DaggerSession1 to start kube, then I start DaggerSession2 to run ToDoListApp, build and publish to the container registry, and deploy into DaggerSession1's kube
Is there anything special I might need to do to expose a debugging port in DaggerSession2?
Just thinking out loud here a few different options, I could run my debugger in daggersession2, or as a service in daggersession1 kube, and expose the port to host. I'm not sure which way would be harder to work with
Is there anything special I might need to do to expose a debugging port in DaggerSession2?
no, as long as your k8s service is exposing the debugger port, you can use the same service tunneling capabilities to connect from your local machine
you could also run kubectl proxy from another session against your kube cluster and tunnel that
there's multiple options
how does tilt currently do it?
the main drawback that dagger still doesn't implement is "live reloading" https://github.com/dagger/dagger/issues/6990
It's under our radar, just don't have the bandwidth to tackle it yet.
vanilla port forwarding is how you might do it with tilt, similar to docker compose watch. Tilt itself i is agnostic and doesn't have debugger specific configuration. For the purposes of this discussion we can probably say that tilt is analagous to docker compose watch, but for kube