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

VSCode as kubectl editor is not returning to terminal until I quit VSCode completely #1616

Closed
parveenksharma opened this issue Jun 28, 2024 · 5 comments
Labels
kind/support Categorizes issue or PR as a support question. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@parveenksharma
Copy link

On my mac Ventura in my ~/.bash_profile I have :
export KUBE_EDITOR='open -a "Visual Studio Code" --wait'

and it is opening the new VSCode window with command on terminal:
kubectl edit pod fooapp

The problem is once I am done editing the yml and save it and close the associated VSCode window the control is not returning to terminal.
For that I have to Quit VSCode completely.

This is very inconvenient as this is resulting in closing all my other open / work in progress files with VSCode .

Please suggest.

@parveenksharma parveenksharma added the kind/bug Categorizes issue or PR as related to a bug. label Jun 28, 2024
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jun 28, 2024
@ardaguclu
Copy link
Member

/kind support
/remove-kind bug

@k8s-ci-robot k8s-ci-robot added kind/support Categorizes issue or PR as a support question. and removed kind/bug Categorizes issue or PR as related to a bug. labels Jun 28, 2024
@brianpursley
Copy link
Member

@parveenksharma

Do either of these work better?

export KUBE_EDITOR='open -a "Visual Studio Code" --wait --new-window'
export KUBE_EDITOR='code --wait --new-window'

@mpuckett159
Copy link
Contributor

I suspect that Visual Studio Code is doing something that prevents kubectl from detecting if the window that was spawned is ever closed, and so it thinks that the edit is still in progress and you have to kill the entire VSCode process to get it to see that the window is closed. This feature was created quite a while ago and I think it expects there to be separate process or something that it can watch to stop and the way VSCode works doesn't allow for that. If these suggestions that Brian made don't work, I don't think we can accomadate how VSCode works unfortunately.

/close

@k8s-ci-robot
Copy link
Contributor

@mpuckett159: Closing this issue.

In response to this:

I suspect that Visual Studio Code is doing something that prevents kubectl from detecting if the window that was spawned is ever closed, and so it thinks that the edit is still in progress and you have to kill the entire VSCode process to get it to see that the window is closed. This feature was created quite a while ago and I think it expects there to be separate process or something that it can watch to stop and the way VSCode works doesn't allow for that. If these suggestions that Brian made don't work, I don't think we can accomadate how VSCode works unfortunately.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/support Categorizes issue or PR as a support question. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

5 participants