Closed bojanz closed 8 years ago
@bojanz Curious for updating my own drupal_ti phpunit-tested modules using composer_manager. Is there a reason in https://github.com/commerceguys/commerce/blob/bec25f7e213fd53c3fdbe98b5aed5adbdf7b951f/.travis-before-script.sh why the composer_manager module isn't enabled first as per the instructions? Or why composer drupal-rebuild
is used instead of composer drupal-install
?
"composer drupal-install" is just "composer drupal-rebuild" + "composer install". However, it can't accept arguments (symfony console limitation), and we need to pass "--prefer-source" to composer install in order to get around API rate limitations. So we use the two commands separately.
As for the module, it doesn't need to be enabled, since it just provides a reports page on the Drupal side. The actual logic is inserted via the init.php script and runs regardless of the module status.
Hrm, ok I may just lock in using the previous hash of composer_manager in our modules until everything is sorted out then.
@bojanz I am pretty sure you should be using the 'phpunit-core' runner for commerce in 8.x.
phpunit runner should be used for modules using the 'pure' oop way of declaring dependencies on libraries via composer.json, and loading those from a tests/ directory.
e.g.
cd tests composer install phpunit
This is especially useful for modules not depending on D8 Core or D7 core in their interfaces.
I tried to switch to id, but got:
Could not read "core". Error: /home/travis/.composer/vendor/lionsad/drupal_ti/runners/phpunit-core/script.sh exited with a failure.
We figured this out in IRC - that was core vs. autoloader vs. modules problem.
Closing as there is nothing drupal_ti can do for that at this moment.
Commit: https://github.com/commerceguys/commerce/commit/bec25f7e213fd53c3fdbe98b5aed5adbdf7b951f
Result:
https://travis-ci.org/commerceguys/commerce/jobs/76440492
Probably needs a similar fix as https://github.com/mradcliffe/drupal_ti/commit/729b8069bbf321978430b509f9c172ef837ebdd9