After #2154225: Switch Behat widget tests to use "Landing page", our tests have started taking about twice as long on Travis-CI. We even hit the 50 minute limit on a couple jobs!
I suspect it's because of the cache clear in FeatureContext::bootstrapDrupal():
/**
* @BeforeScenario @api
*
* Bootstrap Drupal so that all Drupal API functions work.
*/
public function bootstrapDrupal($event) {
if (!$this->bootstrapped) {
$drupal = $this->getDriver('drupal');
// We are experiencing a weird issue where the CTools plugin cache gets
// corrupted and none of our Panels pages work because their layout
// plugins can't be found. It appears that clearing the cache, and then
// bootstrapping Drupal again will fix it! I suspect the CTools plugin
// cache is being built too early, ie. before we change to the Drupal
// directory - but I haven't been able to confirm that.
$drupal->clearCache();
$drupal->bootstrap();
// We occasionally get errors about not finding the ctools_get_export_ui()
// function, so we force it to be loaded. No idea what's causing this.
ctools_include('export-ui');
$this->bootstrapped = TRUE;
}
}
However, the tests won't work at all with out that. :-/
Once we confirm this is the problem, there are two options I can think of right now:
- Come up with a way to only clear the CTools plugin cache, rather than clearing all the caches, or
- Running the tests from the Drupal directory, so that it never has trouble finding the CTools plugins
Comments
Comment #1
mglamanHere is a patch to clear only ctools cache. I wasn't able to rebuild Panopoly due to jquery.imgareaselect failing to download (argh.) But our fork of Panopoly Tests continued fine without error by changing this out.
Comment #2
dsnopekSweet! Was there a performance increase? When I get a chance, I'll run this on Travis-CI and see how it goes.
Comment #3
mglamanYes, I felt there was an increase. I was going to do more review and see if the cache clear can be more specific. But ran short on time before dinner! And this way there is a test to patch and increase performance while more in depth testing can be done!
Comment #4
dsnopekI kicked off a build on Travis-CI:
https://travis-ci.org/dsnopek/panopoly/builds/33813720
It's without the upgrade tests, although, maybe I'll do the next one with them, since it'll give us a lot of times to compare.
Comment #5
dsnopekDoesn't work! The error which was the original reason for the cache clear is happening.
Comment #6
mglamanI'm scratching my head here wondering why, but this works. For some reason menu_rebuild() has magical properties. I reconstructed drupal_cache_clear_all() to its fullest and stripped away each part. I discovered that menu_rebuild solves our woes.
Comment #7
dsnopekNew build for the new patch:
https://travis-ci.org/dsnopek/panopoly/builds/33843006
Comment #8
dsnopekLooking good so far! And now one with the upgrade tests:
https://travis-ci.org/dsnopek/panopoly/builds/33844983
Comment #9
mglamanStill going through upgrades, but https://travis-ci.org/dsnopek/panopoly/builds/33844983 is showing to be about 15 minutes faster per build versus previous ones.
Comment #10
dsnopekWoohoo! Thanks, Matt, for digging into this!
Here's an image of the final times:
Do you know if the
chdir()stuff is necessary withmenu_rebuild()? I know it would be forregistry_rebuild(), but maybe we can skip it withmenu_rebuild(). Also, do you know if the 2nd$drupal->bootstrap()is needed? Behat should already have called that before this function even ran. If it's not needed, then we might save even more time by removing that.Comment #11
mglamanI don't think the chdir() is required, and probably not second bootstrap. Let me test!
Comment #12
mglamanWe can run the test without invoking
$drupal->bootstrap, however removing thechdir()causes registry errors when runningmenu_rebuild()here is updated patch.
Comment #13
dsnopekKicked off a new build:
https://travis-ci.org/dsnopek/panopoly/builds/33907949
Comment #14
mglamanSeems inconclusive, but I'm sure less code can't hurt : )
Comment #15
dsnopekInconclusive time-wise, but definitely less code is better. I'd rather not double bootstrap Drupal if we don't have to. :-)
Comment #16
mglamanHere's a re-roll with updated member variable and method, plus added more appropriate documentation comment.
Comment #17
dsnopekThanks, looks great! I'm going to mark RTBC while I run one last test run with the variable/member rename.
EDIT: Here's the link: https://travis-ci.org/dsnopek/panopoly/builds/33924552
Comment #19
dsnopekCommitted! Thanks, @mglaman, for all your hard work on this!