Design proposal for new Debug Events

[briandealwis]

Description

Design proposal for new Debug Events to be raised by skaffold debug.

Issue: #2211

User facing changes

n/a: no such events are currently being emitted, and existing events are unchanged.

Reviewer Notes

• The code flow looks good.
• Unit test added.
• User facing changes look good.

[briandealwis]

@quoctruong @sujit-kamireddy @etanshaul

[quoctruong]

What is the best way to map a debugEvent to a portEvent? Is it by comparing podName and containerName?

[briandealwis]

And namespace.

[briandealwis]

The debug-events will be raised before the port-events since debug-events will be raised when the container is started, and that's when the port-forward will be initiated.

[codecov]

Codecov Report

Merging #3122 into master will increase coverage by 0.01%.
The diff coverage is n/a.

Impacted Files	Coverage Δ
pkg/skaffold/jib/jib_init.go	89.55% <0%> (+0.66%)	⬆️

[nkubala]

this looks pretty good to me. one question I have is, will this surface any changes to the internal state tracked by skaffold during the run? i.e. the payload the you get back from hitting the /v1/state endpoint.

[nkubala]

this is actually pretty huge. so we could just send a debug payload to skaffold, and request to open up a debug session on a port at any point during the dev session right? in theory, this would allow debugging during a normal skaffold dev loop wouldn't it? or is it required that we modify the container podspecs beforehand

[briandealwis]

We'd still need to have modified the pod specs, though that could be done on-the-fly.

[briandealwis]

Added example of state addition too.

[sujit-kamireddy]

As the local source location is needed by both IJ and VSCode extensions, can we have a way to store this info in the skaffold.yaml configuration?

[sujit-kamireddy]

With this, we don't need to create a 'debug' node in the vscode launch configuration.

[briandealwis]

The local source root is unfortunately not really clear — certainly the debug portion has no more information than the skaffold.yaml's artifact context directory. Consider a source layout like:

path/to/my/artifact/
├── Dockerfile
└── some
    └── deep
        └── directory
            └── RandomPython.py
            └── RandomPython.py
            └── RandomPython.py
            └── RandomPython.py
└── another
    └── deep
        └── directory
            └── RandomPython.py
            └── RandomPython.py
            └── RandomPython.py
            └── RandomPython.py

where the Dockerfile is:

COPY some/deep /random/place/in/image
COPY another/deep/directory /another/place/in/image
WORKDIR /a/different/location

I suspect we'll find it worthwhile to develop a little Go utility to guess at possible source roots, (if something like this doesn't already exist?).

[tejal29]

DD looks good to me. As we discussed the "optional the container image's remote root for source file resolving" is the only matter of concern. If IDEs could resolve it, it would be great!

#LGTM