-
Notifications
You must be signed in to change notification settings - Fork 26
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
Please rethink how Docker runtime arguments are stored #243
Comments
I've added a User Story to our backlog to move our debugging customization to launch profiles rather than being project properties. For the interim you can use project configurations and property conditions to allow for storing multiple sets of settings and switching between them in the UI without editing the project. In the meantime to answer some of your questions:
For your related note: @pratiksanglikar I believe you opened a bug on the space in the name issue. Do you know what the timeline for that fix being released is? Lastly, although we are planning to add support for debugging customization to the launch profile. I am not sure if the run arguments will make the cut. For performance reasons we reuse the existing container across debugging sessions as much as possible. Any change to the run arguments would invalidate it and slow down F5. What exactly are you needing to frequently change in these arguments? Like the environment variables, it may be possible to support the customization w/o restarting the container. |
Hi @NCarlsonMSFT, the space in the name issue is still active. My best guess is that it will go in 16.6 P3. |
@NCarlsonMSFT Thanks for the clarification on Since you've got this as a user story, could you please share the template proposed for
which is then executed? |
Current proposal would be to mirror the launch profile for .Net Core locally. It would look something like:
executablePath would supersede DockerDebuggeeProgram |
Thanks but it's still unclear. Lets assume two cases shown below - could you post their corresponding 1. Single docker command, multiple docker argsHow does one express a docker argument list like
Doesn't seem like 2. Multiple docker commands, multiple docker args eachStarting an app container on multiple docker networks requires it to be broken into multiple stages like
How would it's I'm concerned that the Docker CLI is far too expressive and |
@SidShetye For the first case:
|
@NCarlsonMSFT : Regarding the complex case of multiple docker commands, multiple args: A compose file would actually be better but we're unsure about the road-map since Docker's Regarding the simpler case, I can appreciate that you're trying to break everything down into the existing
Why won't you support allowing users to simply provide you the docker CLI string they want for a given |
@SidShetye, I would use Docker Compose for your scenario. I talk with the Docker Inc folks often and Compose is not going away! |
I fully support this request. I'm currently working on a project where I need to provide some environment variables to my containers when starting it (typically using -e argument in docker run command line), but some of these parameters are connection strings, which means that I don't want these values to be pushed to source control. |
@ncoussemacq setting Environment Variables for the debuggee using the launchsetting's environmentVariables property is already supported today. |
It would be nice to be able to reference multiple .env file paths in launchSettings.json, similar to Docker Compose, instead of setting individual environment values, then setting those again in Docker Compose, and separately for the Project launch profile, etc. Passing the "--env-file" arg of the docker run command and would allow a single .env file format across debug (project, Docker, DockerCompose) and also directly compatible with helm/k8s configmap and secret env mounts. Actually, project debugging doesn't support this either, but I make use of DotNetEnv to import my env files into the project debug runtime. We're going to use the EDIT: We found that |
Docker runtime parameters are currently stored in the
DockerfileRunArguments
This is limiting because project has only a single
csproj
file hence single<DockerfileRunArguments>
. This forces people to constantly edit that file to provide parameters based on different scenarios. The natural place seems to belaunchSettings.json
.Moving to that
launchSettings.json
, it does have aDocker
profile withcommandLineArgs
andenvironmentVariables
but they do not work well.By that I mean
commandLineArgs
vs<DockerfileRunArguments>
- ?environmentVariables
vs<DockerfileRunArguments>
? I've seen variable inenvironmentVariables
sometimes get ignored.My thoughts are allowing people to directly express the docker run arguments (instead of an unnecessary and unreliable abstraction like
environmentVariables
). In fact I'd recommend deprecating<DockerfileRunArguments>
and having the entire run arguments incommandLineArgs
. Additional creature comforts could be supporting line breaks so it's not an unreadable mess of hundreds of characters but for starters just having a single runtime arg that works across various profiles would be great.On a related note, even the profile name
"Docker": { ... }
cannot be renamed to something likeDocker PreProd
etc without breaking things.Expand for tools version
The text was updated successfully, but these errors were encountered: