You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The CLI doesn't have a native ability to run a project inside a container, while Visual Studio and Visual Studio Code do via Docker tools plugins for those respective editors. We should expand this support to the CLI via a new launch profile launch type, so that the intent to use a container can be uniformly expressed. Then any tooling that wants to launch a project as a container natively could interpret this launch profile type and map that to whatever mechanism of action was correct for that environment.
Describe the solution you'd like
We should define a new launch type that directs the host to create a container for the project in question, then executes it. This launch profile should be able to control key aspects of the container execution, including:
container engine to use
(docker/podman/other - our current default is docker)
arguments to provide to the application
optionally - completely overriding the entrypoint?
environment variables to specify when the container runs
volume mounts to create when the container runs
useful for config, secrets, etc
ports to map when the container runs
if not specified, the host could map to random available ports
Team Triage: Marking for 9 for now but it'd be good to understand prioritization here. Additionally, launch profiles were originally a web-focused feature and who would do this work as a bit nebulous. CC @vijayrkn for his thoughts around launch profiles going forward.
Is your feature request related to a problem? Please describe.
The CLI doesn't have a native ability to run a project inside a container, while Visual Studio and Visual Studio Code do via Docker tools plugins for those respective editors. We should expand this support to the CLI via a new launch profile launch type, so that the intent to use a container can be uniformly expressed. Then any tooling that wants to launch a project as a container natively could interpret this launch profile type and map that to whatever mechanism of action was correct for that environment.
Describe the solution you'd like
We should define a new launch type that directs the host to create a container for the project in question, then executes it. This launch profile should be able to control key aspects of the container execution, including:
References
cc @DamianEdwards @davidfowl @danegsta
The text was updated successfully, but these errors were encountered: