Open kenorb opened 8 years ago
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.
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 ...
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.
The problem with using:
which drush and dirname is that it can be a symlink and then the logic starts to get complicated.
In
drupal-7.sh
anddrupal-8.sh
there is a command which run drush in the following way:so I've the following error:
Since I'd like to have my
drush
available globally as I'm usingdrupal_ti
on top of my other CI tests, I've specified the following environment variable:COMPOSER_BIN_DIR=~/bin
which automatically linkdrush
binary into~/bin
which is available by default in Travis CI by just runningdrush
(so I don't need to modify myPATH
). This way is also described indrush
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 installingmailcatcher
, so there can be some tests related to received e-mails):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 bycatchmail
.