Change:
defer os.RemoveAll(srcFile) tests := map[string]struct { <ins> src         string </ins> dest        string expectedErr bool }{ "copy to directory": { <ins> src:         srcFile, </ins> dest:        "/tmp/", expectedErr: false, }, "copy to root": { <ins> src:         srcFile, </ins> dest:        "/", expectedErr: false, }, "copy to empty file name": { <ins> src:         srcFile, </ins> dest:        "", expectedErr: true, }, <ins> "copy unexisting file": { src:         path.Join(srcFile, "nope"), dest:        "/tmp", expectedErr: true, }, </ins> } for name, test := range tests { opts := NewCopyOptions(ioStreams) src := fileSpec{ <del> File: srcFile, </del> <ins> File: test.src, </ins> } dest := fileSpec{ PodNamespace: "pod-ns",

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Running silently fails if that source file doesn't exist. What you expected to happen: I expected kubectl to exit with a non-zero status code and to print a standard error message like so: How to reproduce it (as minimally and precisely as possible): Find any running pod, try to copy a non-existent file: Anything else we need to know?: works right. For example: I'm sure this has something to do with the fact that uses under the hood. However, itself will report an error if you try to extract a file that doesn't exist, so maybe this is just a matter of not including the to-be-extracted-path(s) on the end of the tar command line. This might be fixed by appending (or rather the basename of it) to the end of the array here: (haven't tried it). Environment: Kubernetes version (use ): and Cloud provider or hardware configuration: docker-for-desktop 2.0.4.1 () and GKE running 1.13.6-gke-0 OS (e.g: ): macOS 10.14.5 Kernel (e.g. ): Install tools: Installed docker from dmg, using the included Network plugin and version (if this is a network-related bug): Others:
/assign /sig cli
any update on this?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Same issue when the file doesn't exist on the pod
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Beep
Rotten issues close after 30d of inactivity.

Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
This is the first example where I found the kubectl cli to be sub-par (otherwise the experience has been excellent). Is anyone looking at this?
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
For me never copies anything and never writes any info to console. Even if I point it to non-existing pod, it just exists with no trace.
I've opened with a fix.
: what version of kubectl are you using? I tried to upload a file to a non-existent pod and it failed with an error message (using the master branch) :
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Any maintainer here? I had opened with a fix.
Would be great if would return a simple error in the CLI. Our pipeline was failing for a month and none realised because all the kubectl results were green :heavycheckmark: