Added #env-vars for adding environmental variables to Drush commands

[mortenson]

Following a discussion in Issue #950, I have added a path-aliases option to add arbitrary environmental variables to generated Drush commands. This is useful for Drush users who have setups that require an environmental variable to be set for every Drush execution.

In my case I needed to send a dynamic variable to the my %drush-script, but there are likely other use cases for this as well. In my example, the %drush-script looks like:

!#/bin/bash
sudo -u $DRUSH_USER drush $@

and my site record looks like:

...
    'path-aliases' => array(
      '%drush-script' => '/home/mortenson/drush.sh',
      '%env-vars' => array(
        'DRUSH_USER' => $user
      ),
    ),
...

In this example, a dynamic $user is used to run Drush commands. I'm willing to change my approach to this if anyone has any suggestions.

[greg-1-anderson]

Looks pretty good. %env-vars does not contain a path, though, so it should just be $site_record['%env-vars']; instead of $site_record['path-aliases']['%env-vars'];

[mortenson]

I'm new to Drush contribution - what's the significance of the percent sign? I'm wondering if it should still have it if I move it higher up in the Site Record.

[greg-1-anderson]

You're right -- as a top-level element, it should be '#env-vars'. Truthfully, there isn't a lot of consistency here, but the # will prevent backend invoke from attempting to add env-vars to the remote command as commandline options. The simple fact that this variable is an array would serve the same purpose, really, but still, it is best to not leave it 'naked', so that it does not look like an option.

[greg-1-anderson]

The other thing I was just wondering about was, what if someone wanted to define command-specific environment variables? We do not necessarily need to support that; it was just a thought.

[mortenson]

Thanks Greg, I made the change to add #env-vars to the top-level of the site record. As the code is now, users would have to replace the values of the site record temporarily in their call, for example:

drush_invoke_process(array_replace_recursive(array("#env-vars" => array("KEY" => "Value")), $site_record), 'pm-updatestatus');

Which would override the default value of $site_record['#env-vars']['KEY'] for that call. If there was a Drush hook for modifying commands before they were generated (i.e. hook_drush_build_drush_command) users could more easily add this logic in.

[mortenson]

Is there a way to re-run tests? I'm not sure why the last one failed as I changed almost nothing.

[greg-1-anderson]

I had the same question! The Drush Make tests appear to be failing sporadically now. The failure above is unrelated to your changes; there was just a make test where the build's checksum did not match the expected outcome.

Regarding your suggestion vis-a-vis drush_invoke_process, yes, that would work for per-instance changes to environment variables, but I was thinking more along the lines of inserting 'command-specific' => array( 'my-command' => array( '#env-vars' => array( ... ) ) inside an alias record, to specify the environment variables to use for just that one command.

I don't think that the command-specific mechanism in Drush works in the right way for this to work; the functionality would have to be duplicated in backend invoke. I don't really have a use case at this time, so I think we can just punt on that for now.

I'm satisfied with the patch as submitted.

[jonhattan]

Re-run the tests. Now it's green.

[weitzman]

You can rerun the tests if you are sufficiently privileged in Travis.There is a recycle icon whose alt text is 'restart build'. No idea how I can add more admins.

Thanks @mortenson.