-
Notifications
You must be signed in to change notification settings - Fork 62
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
Feature Request: Allow saving connection to settings.json #368
Comments
+1 on this, my team have the same usecase and we are trying to automate as much as possible. |
+1 Also, credentials should be hidden by encrypting them or by referencing environment variables. I don't know if it is already possible in settings.json because the documentation mentions launch.json and tasks.json only. Given these possibilities, I could provision the remote environments and provide the developers with the connections they need on a per-repository basis. |
+1, I'm using the MongoDB extension in a devcontainer with a backing docker-compose file. It would be amazing to pre-populate the interface with a connection. |
Same problematic here. And I can't find how to access secrets on my docker container to eventually replicate the information across machines... Any help is highly appreciated if you managed a way! Thanks for the amazing extension by the way |
+1 daily use the same setup, mongo in a compose based devcontainer or codespace, with the mogo extension, and have to add back the connection information every time a new user picks it up. |
+1 I also need this feature for using this extension in a DevContainer and to backup the list of connections. @alenakhineika Any plan for this? |
This seems like a reasonable request. There's the obvious risk of storing credentials in a plaintext file, but if you're comfortable with that, I don't see a problem with providing the option. Looping in @GaurabAryal, who's our PM to see where we can fit this among the other tasks we're working on. |
I have 5 different DB connections in my project (it's a monorepo contains multiple projects) and I prefer to share them with my team members. These are mostly local DBs that we are using for the local development so no important credentials included. As @damienpontifex suggested I prefer to set them through a setting like this:
|
+1 from my side, use the predefined environment with the code-server, and it would be great to describe the default connections in the settings.json |
Guys @damienpontifex @langaads @seesharprun @sposetti @BabakScript @adriano-di-giovanni @coderhammer @jrussellsmyth @nirinchev But it would be really helpful if you vote for this feature request on MongoDB's ideas portal: https://feedback.mongodb.com/forums/929236-mongodb-for-vs-code/suggestions/41913550-predefined-connections-array-on-settings-this-hel *according to @alenakhineika's comment, the ideas feedback portal uses for prioritizing the feature requests from the community, and if we all vote up, this feature(with already 6 existence votes) will be at the 5th place(with 15 votes) over all ideas in the list |
Hey, thanks for raising this, I am going to start working on the solution for this usecase; likely as a setting one can manually set through |
Feature Request
Ability to save connections into settings.json within the opened folder context (i.e. .vscode/settings.json) or within the devcontainer context (i.e. .devcontainer/devcontainer.json under the key "settings")
Context
Especially useful when combining VS Code remote containers and docker compose to startup the mongodb container within the workspace and have it automatically configured to be connected to the container within this setup.
As an example of how the MSSQL extension does it and then this can be added to .devcontainer/devcontainer.json
See dotnet-mssql remote container template https://github.com/microsoft/vscode-dev-containers/tree/main/containers/dotnet-mssql for how they utilise remote containers and the mssql container for a great dev environment setup. Looking at a similar scenario with any language + mongodb as the data store
Possible Implementation
settings.json
The text was updated successfully, but these errors were encountered: