search

jeansaad / chalet

🏩 A simple process manager for developers. Start apps from your browser and access them using local domains
MIT License
156 stars 19 forks source link

Team shared servers config #12

Open danielkcz opened 3 years ago

danielkcz commented 3 years ago

Thank you for keeping this alive @jeansaad. It's hard to find some nice GUI for development on Windows.

I understand the utility is meant to be used locally, but there is also a nice opportunity to set up a dev environment for a new team member. They could simply configure their chalet to use servers from a folder that's versioned in the VCS.

Probably the easiest approach would be to add a configuration option with a list of additional folders with servers and it merges it all together. I could work on the PR if you think this is a good idea.

Maybe there is a viable approach through Docker, but I am mostly a front-end guy, so I am not sure.

jeansaad commented 3 years ago

Thanks for submitting this issue @FredyC. I am also using this tool in the team capacity and never really thought of checking them into VCS, so I welcome the addition entirely.

Before I get into potential solutions, a cheap way to achieve this would be to commit whatever you like in your VCS and add a symbolic link to it in your <HOME>/.chalet/servers folder. So if this is something that you want to do today, it seems entirely possible.

The only issue that I can think about when committing the configs to a VCS is path structure and things that could be potentially sensitive, like secrets in environment variables. Chalet takes a snapshot to your PATH variable so ideally these issues need to be thought out more.

Maybe we can create a special configuration file that you can check into VCS and when u run chalet add you can pass in that file that will help you register the service into chalet. How does something like that sound? Obviously, the user is responsible re-registering the service if there are updates.

Happy to hear any ideas or thoughts!

danielkcz commented 3 years ago

Yes, you are right about the path and sensitive stuff. I've realized it later as well when I tried the symlink approach.

Some intermediate shareable config could be surely a solution. I would probably introduce commands like chalet import/export instead of mixing that to add. It could possible to specify which servers to import (all by default) and some override mode in case of later updates.

Unfortunately, this isn't a priority for me now, so I won't be able to work on it as I advertised. Feel free to take a stab at it if you have some capacity.

jeansaad commented 3 years ago

I like the suggestion for chalet import and chalet export for creating the configuration. What I found to be useful when helping others set it up is given them a list of commands that are mostly portable. Maybe we can somehow capture those commands in the shareable config.

Just out of curiosity, would you have any interest in specifying multiple servers in the same file? I am thinking that this should be possible.

Let me think up of a spec for how this file would look like. It might be easier to start with chalet import and a spec for the file that can be hand-crafted at the moment. The export case is a little more complicated because we don't necessarily know what should be whitelisted/blacklisted in terms of ENV vars. I can probably assume that PATH is excluded but beyond this, the scenarios will vary with different environment variables.

danielkcz commented 3 years ago

I think the config file for VCS should have more server configs for sure. It's not that bulky to have it in multiple files imo. And it would complicate import if you would have to specify a directory that might have other files.

About secrets on export, it would be probably best to expand servers config and specify a list of names of "exportable" env vars. Anything unspecified would be private.

jeansaad commented 2 years ago

Haven't forgotten about this @FredyC! It is something that I would like to make time for but would like to re-work some of the code to get it in a good spot as well as re-think the configuration strategy. Most people often write code that accompanies any deployment so making a VCS-like configuration drive this might eventually remove the need for a cli import or at least make it configuration based. That way anyone can check in the file to their VCS and make sure they don't lose configuration when switching to a new machine or sharing the code with others.