drupalextension
drupalextension copied to clipboard
jhedstrom
Re-enable testing with the Drush Behat Endpoint.
Packagist for some reason did not see the 1.1.0 tag right away, so the first run here installed 1.0.0 (which does not have the Drush 9 version). Oh, come to think of it, this PR will continue to fail until Drush 9.5.0 is released.
There are still failures with taxonomy terms in the Pantheon tests. Hopefully I'll have these cleared up soon.
@jhedstrom It's getting pretty hard for me to keep track of how everything is installed for these tests. I'm not sure how things are supposed to work here; when I run the commands from the travis.yml locally, then drush help behat works, but in Travis it doesn't work and I'm not sure why.
Would it be all right with you if I installed Drupal via drupal-composer/drupal-project instead of drupal/drupal, and include the drupalextension SUT via a Composer path repository? That would make it easier for me to ensure that the Drush Behat Endpoint is installed to drush/Commands & is also in the same autoloader as Drupal and the SUT.
Note: if you look at the tests here, only look at the ones for Drupal 8 / Drush 9. There's a bug here ATM where Drush 8 tries to load the Drush 9 version of the Drush Behat Endpoint instead of the Drush 8 version, which is why all of the Drupal 7 tests are failing.
OK, taxonomy terms are working again in my other test suite. 🎉
Still need to decide how to differentiate the Drush 9 version of the Drush Behat Endpoint from the Drush 8 version, and make the install steps work here. I think I might convert the Drush 9 version into a module.
Hmm, this makes it look like perhaps an old version of the DrupalDriver is now getting installed?
PHP Fatal error: Call to undefined method Drupal\Driver\DrupalDriver::startCollectingMail()
Perhaps. You wanted me to put the drupal/drupal-driver constraint back into the Behat Drush Endpoint, so I did. I used ^1. Is that right? Is it perhaps getting in the way of testing?
It could also have something to do with the fact that I set minimum stability to dev globally, because I was getting stable versions of Drush even when I requested the 9.x-dev release explicitly. I think I'm going to leave this particular issue alone until Drush 9.5.0 is released; once that happens, it won't be necessary to force a dev version of Drush.
I used ^1. Is that right? Is it perhaps getting in the way of testing?
Ah, yes, it should probably be ^2 now as substantial work has been done in DrupalExtension that depends on that now for the 4.x branch (currently still master).
Yeah, it's saying:
- Installing drupal/drupal-driver (v1.4.0): Cloning 919c6a39ef from cache
Maybe I'll try just setting the version constraint to *.
I duplicated some installation code from the Drupal 7 case for Drupal 8 and adjusted it, but accidentally left a require drupal-driver in the cut-copy-pasta. Fixed that in fa6a8ce; we'll see if that helps.
The situation is greatly improved, but I see that there are some failed drush tests that seem to be running Drupal 7 tests against a Drupal 8 SUT. Maybe I didn't set up the test correctly for this scenario
Most tests are passing now. I suspect that all tests will pass once the Drush driver is updated to not use drush cache-clear all with Drush 9.
@jhedstrom I'm not sure why Travis won't clone from my PR; seems like I've done this sort of thing before (and recently) without a problem. Maybe you can just merge https://github.com/jhedstrom/DrupalDriver/pull/198 and tag a new alpha release.
Travis won't clone DrupalDriver PR: https://travis-ci.org/jhedstrom/drupalextension/builds/431459950?utm_source=github_status&utm_medium=notification
Most test passing, cache-clear failing: https://travis-ci.org/jhedstrom/drupalextension/builds/431445276?utm_source=github_status&utm_medium=notification
OMG the tests are green!
Probably want to wait for tagged releases in DrupalDriver and Drush before finishing up here and merging.
Updated .travis.yml to use the stable release of Drush. Perhaps this is good to go now?