🐛 Don't remove container created by "Run Image" automatically

[xgdgsc]

solves #1217

[bwateratmsft]

Seems like we should have a setting controlling this? @philliphoff what do you think?

[philliphoff]

@bwateratmsft While I empathize with losing work within an unintentionally-exited container--that sucks!--given the intentionally ephemeral nature of containers, I'm not sure simply removing --rm from the command is the best option (even aside from the change to today's behavior). That said, I would support an extension-level setting that allows the user to disable use of --rm switch for those commands.

[StephenWeatherford]

I've always wanted to have settings to control args for all these commands. It would need to be done in a well-planned way.

[bwateratmsft]

I've always wanted to have settings to control args for all these commands. It would need to be done in a well-planned way.

@StephenWeatherford That's fair. I think then it would be related to #38. If we make the container run a task, the user can specify anything as options to the task (including --rm and anything else). However, tasks only make sense in the context of a workspace so it's not a perfect solution...

[eine]

Related to #1001 and #1494 (#331), I think that 'Run' should open a parameter selection menu with multiple select and text boxes boxes:

• Select boxes:
  • daemon, interactive: mutually exclusive.
  • rm
• Text boxes:
  • port
  • volume
  • any

Defaults might be set by the caller, so that different preset options are shown depending on 'Run', 'Run Interactive' or if the source is a Task (#1311). If the user does not want to change anything, just hitting enter will work. Those who want to do one-time modifications can do so without modifying files or manually writting the command in the terminal.

[bwateratmsft]

This will be resolved by #1596 / #1649