We have a lot of environment variables. It is becoming hard to document them all. Should we start using a tool like dotenv[1]? Looks like it is the most popular configuration management gem for Ruby[2].
1: https://rubygems.org/gems/dotenv
2: https://www.ruby-toolbox.com/categories/Configuration_Management
Version: wmf-deployment
Severity: normal
I like the idea of using this in tandem with mw-vagrant since it would allow for extension-specific variables, but I'm not sure we should actually commit the .env file; it should be provisioned by puppet.
If we commit the .env file, we can get rid of some ugly hacks that we have at the moment. For example, the entire url_module.rb in mediawiki/selenium[1] and MobileFrontend[2].
We can get rid of those hacks (and we should!) regardless of our use of an .env file.
As I understand it, this is more about simplifying setup outside of something like mw-vagrant where the environment variables are not set for you—i.e. it obviates the requirement to source environment variables into the current shell before executing cucumber.
While I think simplification of setup is definitely a worthwhile goal, standalone use of mediawiki_selenium outside of mw-vagrant will become increasingly marginal as adoption of the latter picks up. If we commit the .env file, overriding it will be problematic—it will show up in people's git status—and it's utility within mw-vagrant becomes nil.
What if we commit a .env to mediawiki_selenium but leave it out of extension repositories? That way we have a nice place to store global ENV defaults, but still allow for clean local overrides in mw-vagrant.
@dduvall: you have decided to use environments.yml instead of .env file?
Example:
https://gerrit.wikimedia.org/r/#/c/180324/2/tests/browser/environments.yml,cm
Yes, I think the native functionality for an environments.yml file in the new environment abstraction layer for mw-selenium essentially does what we need, and then some: it supports multiple sets of default environment variables. It's also a bit less invasive than dotenv's implementation, which overwrites the state of ENV, making it less prone to race conditions and easier to test.