"hup" command for use with restart helper

[shaunc]

Is your feature request related to a problem?

Currently, I have a container that, when I'm fiddling with, I like to change the environment, and restart the service, but not recreate the container (which would throw away environment changes). Of course I can also edit the devspace.sh, but these are ephemeral changes and rather not have to be careful to avoid checking in (which could create a security risk).

Which solution do you suggest?

In conjunction with the restart helper, it would be nice to have a "hup" command that restarted the service (without recreating the container). Indeed a command that did both ("hup" with --env option) would be most convenient, as I wouldn't have to enter the container. Or, there could be a "one time sync" command with the --env option, which could have other options (like explicitly copying or not copying certain files).

Which alternative solutions exist?

Currently, I can trigger restart by using sync and touching a dummy file. This works ok... but took me a little while to hit on it. (Alternately this could be added as a "tip" in the documentation without a command.)

Additional context

/kind feature

[FabianKramm]

@shaunc thanks for creating this issue! You can use the devspace command devspace restart to just restart a container without recreating it as long as the container uses the restart helper script. Regarding environment variables, this would be probably rather difficult as the default variables depend on the target shell to use, so I'm not exactly sure how we would approach this.

[shaunc]

Thanks! -- ah; I had overlooked that command. What I had in mind with '--env' wasn't to override the whole environment, but to inject one or several variables into the environment seen by the restart helper, in addition to whatever the default ones defined by OS, kubernetes, and container definition (& etc?). Hmm... perhaps restart helper could source a .restart-env file, which could be synced before restart?

[FabianKramm]

@shaunc ah I see, yes that would be possible. We could add this to the devspace restart command with the flag --env