Skip to content
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

path to drush.php is hardcoded, so drupal_ti doesn't respect COMPOSER_BIN_DIR #66

Open
kenorb opened this issue Dec 16, 2015 · 4 comments

Comments

@kenorb
Copy link

kenorb commented Dec 16, 2015

In drupal-7.sh and drupal-8.sh there is a command which run drush in the following way:

~/.composer/vendor/bin/drush.php

so I've the following error:

php -d sendmail_path=/bin/true /home/travis/.composer/vendor/bin/drush.php --yes site-install testing --db-url=mysql://root:@127.0.0.1/drupal
Could not open input file: /home/travis/.composer/vendor/bin/drush.php

Since I'd like to have my drush available globally as I'm using drupal_ti on top of my other CI tests, I've specified the following environment variable: COMPOSER_BIN_DIR=~/bin which automatically link drush binary into ~/bin which is available by default in Travis CI by just running drush (so I don't need to modify my PATH). This way is also described in drush docs.

So I wondering if there is a better way of running drush. It seems this syntax is only used in order to handle mails (php -d sendmail_path=$(which true)).

In my .travis.yml, my approach is a bit different (by installing mailcatcher, so there can be some tests related to received e-mails):

 - gem install mailcatcher && mailcatcher -v
 - echo 'sendmail_path="/usr/bin/env catchmail"' | tee -a "$(php --ini | grep "Loaded Configuration" | awk '{print $4}')"

In this case, we can install site in normal way, which is: drush --yes site-install, so we're not depending on any hardcoded paths and mails are handled by catchmail.

@LionsAd
Copy link
Owner

LionsAd commented Dec 16, 2015

I think I could just check for COMPOSER_BIN_DIR instead?

Then it would continue to work. This is mainly for the installation, so not affecting other parts.

@kenorb
Copy link
Author

kenorb commented Dec 16, 2015

I think so, in case when COMPOSER_BIN_DIR is defined, running without sudo ~/bin value could be more preferred, with sudo, the /usr/local/bin work better in this case, so it's better to have some more flexible way of finding drush.

Or the same way as drush finding its php file:

SCRIPT_PATH="`dirname "$SELF_PATH"`/drush.php"

in drush (see: vim $(which drush)).

So it can be:

php -d sendmail_path=/bin/true "$(dirname "$(which drush)")"/drush.php ...

@LionsAd
Copy link
Owner

LionsAd commented Dec 16, 2015

As drupal_ti takes care of installing drush and there is no harm in doing so, I think checking COMPOSER_BIN_DIR is enough. It is an edge-case anyway - as hhvm has trouble with the php.ini.

@LionsAd
Copy link
Owner

LionsAd commented Dec 16, 2015

The problem with using:

which drush and dirname is that it can be a symlink and then the logic starts to get complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants