Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

skaffold ko builder issues using skaffold debug functionality #6843

Closed
aaron-prindle opened this issue Nov 11, 2021 · 3 comments · Fixed by #6874
Closed

skaffold ko builder issues using skaffold debug functionality #6843

aaron-prindle opened this issue Nov 11, 2021 · 3 comments · Fixed by #6874
Assignees
Labels
area/debug build/ko kind/bug Something isn't working priority/p2 May take a couple of releases

Comments

@aaron-prindle
Copy link
Contributor

aaron-prindle commented Nov 11, 2021

In attempting to use the ko builder with the sample at skaffold/integration/examples/ko with Cloud Code's Debug on Kubernetes I was not able to successfully setup a debug flow. The app builds and deploys properly and it serves requests but none of the breakpoints trigger as expected for Debug on Kubernetes. My approach was as follows:

# modify cloud code skaffold binary to be latest skaffold built from HEAD
$ cp /usr/local/bin/skaffold-head ./.cache/cloud-code/installer/google-cloud-sdk/bin/skaffold

Open /skaffold/integration/examples/ko in VS Code (w/ Cloud Code installed):

$ ~/skaffold/integration/examples/ko  [main]$ code .

Add some breakpoints to the source code
Screenshot 2021-11-11 11 13 45 AM

Set the following values from the Cloud Code Debug on Kubernetes wizard
image registry: gcr.io/aprindle-test-clusters
directory in the remote container where the program can be found: /ko-app

From this setup, I am able to interact and see the images/deployments which work properly but none of the breakpoints seem to triggering.

aprindle@aprindle ~/skaffold/integration/examples/ko  [main]$ kubectl get po
NAME                  READY   STATUS    RESTARTS   AGE
ko-5dff4dbc6c-hkv27   1/1     Running   0          119s

image

@aaron-prindle aaron-prindle added kind/bug Something isn't working priority/p2 May take a couple of releases area/debug build/ko labels Nov 11, 2021
@aaron-prindle
Copy link
Contributor Author

aaron-prindle commented Nov 11, 2021

@halvards
perhaps something is incorrect in my setup or the args I passed to the wizard (eg: the remote container directory)? Should apps built with ko currently work properly w/ skaffold debug?

@aaron-prindle
Copy link
Contributor Author

Also, the suggested default path in the image (from the Cloud Code Debug on Kubernetes wizards) was /home/nonroot. This should probably instead suggest /ko-app for ko applications (unless I am misunderstanding something)

@halvards halvards self-assigned this Nov 11, 2021
@halvards
Copy link
Collaborator

Thanks for filing this @aaron-prindle!

This is caused by ko adding the -trimpath flag to go build if no build config is provided: https://github.com/google/ko/blob/5617d1ebf8560df778aa884fa328fe05f62bdb5e/pkg/build/gobuild.go#L562

A workaround right now is to use a non-empty flags config field, e.g. ["-v"].

But we should consider ensuring that this flag isn't set when debugging. I'll work with the ko team to determine if it's better to solve it upstream or in Skaffold.

For the VS Code launch configuration, the remote path should match the local path, so you can use a mapping such as this:

            "debug": [
                {
                    "image": "your image name from skaffold.yaml",
                    "sourceFileMap": {
                        "${workspaceFolder}": "${workspaceFolder}"
                    }
                }
            ]

The "remote path" name is misleading IMO, it means "the source path used when compiling the code". For example, when building an image for a Go app using Docker, the full path to the source files will be different in the IDE (the key in the map above) to the full path used when compiling, since the compilation happens in a temporary container. For instance, a Dockerfile may include a statement such as ADD . /src. In that case, the mapping would be "${workspaceFolder}": "/src".

IntelliJ IDEA and Goland appear to work out this mapping automatically.

In addition to a fix for the -trimpath flag, I'll create a PR to improve our docs and ko example.

halvards added a commit to halvards/skaffold that referenced this issue Nov 12, 2021
Update explanation of how Go debugging works in Skaffold and add
explanations for ko builder users.

Also update links to the VS Code Go extension.

Related: GoogleContainerTools#6843
Tracking: GoogleContainerTools#6041
tejal29 pushed a commit that referenced this issue Nov 12, 2021
Update explanation of how Go debugging works in Skaffold and add
explanations for ko builder users.

Also update links to the VS Code Go extension.

Related: #6843
Tracking: #6041
halvards added a commit to ko-build/ko that referenced this issue Nov 17, 2021
Enables programmatic control of whether `ko` adds the `-trimpath`
flag to `go build`.

The `-trimpath` flag removes file system paths from the resulting
binary. `ko` adds `-trimpath` by default as it aids in achieving
reproducible builds.

However, removing file system paths makes interactive debugging more
challenging, in particular in mapping source file locations in the
IDE to debug information in the binary.

If you set `Trimpath` to `false` to enable interactive debugging, you
probably also want to set `DisableOptimizations` to `true` to disable
compiler optimizations and inlining.

Reference for `-trimpath`:
https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies

Resolves: #500
Related: #71, #78, GoogleContainerTools/skaffold#6843
halvards added a commit to ko-build/ko that referenced this issue Nov 17, 2021
Enables programmatic control of whether `ko` adds the `-trimpath`
flag to `go build`.

The `-trimpath` flag removes file system paths from the resulting
binary. `ko` adds `-trimpath` by default as it aids in achieving
reproducible builds.

However, removing file system paths makes interactive debugging more
challenging, in particular in mapping source file locations in the
IDE to debug information in the binary.

If you set `Trimpath` to `false` to enable interactive debugging, you
probably also want to set `DisableOptimizations` to `true` to disable
compiler optimizations and inlining.

Reference for `-trimpath`:
https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies

Resolves: #500
Related: #71, #78, GoogleContainerTools/skaffold#6843
halvards added a commit to halvards/skaffold that referenced this issue Nov 17, 2021
`ko` adds the `-trimpath` flag to `go build` by default, as this aids in
achieving reproducible builds.

The `-trimpath` flag removes file system paths from the resulting
binary, and this makes interactive debugging more difficult.

This change instructs `ko` to _not_ add the `-trimpath` flag when users
run `skaffold debug` with the `ko` builder.

Bumps the `ko` version to pick up the `Trimpath` build option.

Also, simplifies the `ko` example config since it's no longer necessary
to add a non-empty `flags` field to `skaffold.yaml` to allow for
interactive debugging.

Fixes: GoogleContainerTools#6843
Tracking: GoogleContainerTools#6041
tejal29 pushed a commit that referenced this issue Nov 18, 2021
`ko` adds the `-trimpath` flag to `go build` by default, as this aids in
achieving reproducible builds.

The `-trimpath` flag removes file system paths from the resulting
binary, and this makes interactive debugging more difficult.

This change instructs `ko` to _not_ add the `-trimpath` flag when users
run `skaffold debug` with the `ko` builder.

Bumps the `ko` version to pick up the `Trimpath` build option.

Also, simplifies the `ko` example config since it's no longer necessary
to add a non-empty `flags` field to `skaffold.yaml` to allow for
interactive debugging.

Fixes: #6843
Tracking: #6041
tejal29 pushed a commit that referenced this issue Nov 18, 2021
`ko` adds the `-trimpath` flag to `go build` by default, as this aids in
achieving reproducible builds.

The `-trimpath` flag removes file system paths from the resulting
binary, and this makes interactive debugging more difficult.

This change instructs `ko` to _not_ add the `-trimpath` flag when users
run `skaffold debug` with the `ko` builder.

Bumps the `ko` version to pick up the `Trimpath` build option.

Also, simplifies the `ko` example config since it's no longer necessary
to add a non-empty `flags` field to `skaffold.yaml` to allow for
interactive debugging.

Fixes: #6843
Tracking: #6041
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/debug build/ko kind/bug Something isn't working priority/p2 May take a couple of releases
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants