-
Notifications
You must be signed in to change notification settings - Fork 151
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
Support for environment variables in mutagen.yml file #128
Comments
That makes sense to me. I'll queue it up on the roadmap. |
Great, thanks @havoc-io Awesome work by the way :D |
2 things I wish to land with this feature:
beta: '${MUTAGEN_BETA:-root@192.168.1.100:/home/vagrant/projects/my-project}'
sync:
defaults:
alpha: .
beta: '${MUTAGEN_BETA:-root@192.168.1.100:/home/vagrant/projects/${MUTAGEN_SYNC_ROOT_BASENAME}' In this example, MUTAGEN_SYNC_ROOT_BASENAME is provided by MUTAGEN and automatically match the synchronisation root directory name. |
Thanks @Toilal for the additional input. If Mutagen does implement this, having a set of built-in environment variables could be interesting. This would also align well with the In any case, I've been looking at implementing this for v0.11.x, but I'd like to get that shipped ASAP, so I think I'm going to move this to the roadmap for v0.12.x and flag it as a backport candidate for a later v0.11.x release. I've been looking at what other related projects and tools do here and I'm not sure there's a clear consensus on how this should work or whether it should even be supported, so I'm hoping for some additional opinions/feedback. Docker Compose is the simplest case, and it supports a shell-inspired syntax and Helm seems to have rejected environment variables, at least in the incarnation proposed here. Their concerns were security (since the environment variables would need to be bundled and sent to the remote server) and reproducibility. Mutagen's project files don't really have the same security concerns since they're processed locally, but the reproducibility aspect of things is something that concerns me. One of the big benefits of doing containerized development is that you can create reproducible environments that work across a team. Having environment variables that can parameterize a project file do undercut that pretty drastically. Kubernetes also seems to have rejected this idea in favor of recommending external tools like I'm also wondering if we want to restrict these substitutions to only YAML value elements, because that's kind of difficult to implement. It's not difficult to perform a regular expression or So basically 2/3 of the most relevant open-source projects (the newer ones) intentionally don't support this and the one that does support this would be tedious (though certainly not impossible) to emulate with Go. For the time being, I'll take the Kubernetes route and recommend the aforementioned tools as a workaround, but I'd like to hear from other users about (a) how they would use this, (b) what they'd like the syntax to be, and (c) how they'd like this to behave. 1 Using a |
Hey! I also trying to make beta endpoint dynamic somehow. Recently we were created sync sessions from sh scripts, but now I want to create mutagen.yml with all the configurations. @havoc-io I have few ideas:
|
Currently, i use envsubst that parses a mutagen.yml.dist file and re-creates mutagen.yml on each run |
I am not sure if that might work already as I wasn't able to properly test it yet (see #127) but it would be awesome if I could use environment variables in the mutagen.yml files, i.e. for the alpha and beta config.
We use a .env file where a user can specify his own paths and those get used in bash files and in docker-compose files.
The text was updated successfully, but these errors were encountered: