Database access command

[retlehs]

https://github.com/TypistTech/vagrant-trellis-sequel exists for vagrant, but we could also support sequel connections to the remote environments

[tangrufus]

To do so, we need a way to compile site_env:

1. decrypt vault files
2. combine site_env
3. handling ansible variables, example:

   vault_wordpress_sites:
     example.com:
       env:
          db_password: "{{ my_other_variable }}_dbpassword"
   

Any idea how to implement them in golang?

[swalkinshaw]

Your vagrant plugin doesn't do that does it? I looked through it recently and didn't see anything like that.

Evaluating site_env would be most impossible I think? (without just trying to replicate the logic of course). We'd need to parse that file as YAML, then have a Jinja2 parser (which isn't even enough because I think that has custom Ansible filters)... and then eval it in the context of our variables as you mentioned.

[tangrufus]

Your vagrant plugin doesn't do that does it?

The plugin only decrypts vault files but not evaluating site_env nor handling ansible varibles.

It assumes users don't customize any db_xxx values - https://github.com/TypistTech/vagrant-trellis-sequel/blob/cc93696de180ba8e72e80039c9837f0de26bd77c/lib/vagrant_plugins/trellis_sequel/vault.rb#L26-L58

As we are going to support more than vagrant, we should expect users to use all ansible features on their db_xxx values.

Possible solutions:

1. SSH into remote servers + run PHP scripts (or wp cli commands) to get db_xxx values.
2. SSH into remote servers + parse site .env
3. Run ansible-playbook to generate db_xxx values locally, similar to https://github.com/ItinerisLtd/enveigle

[swalkinshaw]

The 3rd option seems best to me? Especially since, as already proven by your enveigle plugin, that functionality on its own is useful. trellis-cli could have a dotenv command

[swalkinshaw]

This has been done for a while since #72