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:

  1. Come up with a way to only clear the CTools plugin cache, rather than clearing all the caches, or
  2. Running the tests from the Drupal directory, so that it never has trouble finding the CTools plugins

Comments

mglaman’s picture

Status: Active » Needs review
StatusFileSize
new1.06 KB

Here 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.

dsnopek’s picture

Sweet! Was there a performance increase? When I get a chance, I'll run this on Travis-CI and see how it goes.

mglaman’s picture

Yes, 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!

dsnopek’s picture

I 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.

dsnopek’s picture

Status: Needs review » Needs work

Doesn't work! The error which was the original reason for the cache clear is happening.

mglaman’s picture

Status: Needs work » Needs review
StatusFileSize
new1.26 KB

I'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.

dsnopek’s picture

dsnopek’s picture

Looking good so far! And now one with the upgrade tests:

https://travis-ci.org/dsnopek/panopoly/builds/33844983

mglaman’s picture

Still 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.

dsnopek’s picture

StatusFileSize
new23.52 KB

Woohoo! Thanks, Matt, for digging into this!

Here's an image of the final times:

Do you know if the chdir() stuff is necessary with menu_rebuild()? I know it would be for registry_rebuild(), but maybe we can skip it with menu_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.

mglaman’s picture

I don't think the chdir() is required, and probably not second bootstrap. Let me test!

mglaman’s picture

StatusFileSize
new1.34 KB

We can run the test without invoking $drupal->bootstrap, however removing the chdir() causes registry errors when running menu_rebuild()

here is updated patch.

dsnopek’s picture

mglaman’s picture

Seems inconclusive, but I'm sure less code can't hurt : )

dsnopek’s picture

Inconclusive time-wise, but definitely less code is better. I'd rather not double bootstrap Drupal if we don't have to. :-)

mglaman’s picture

StatusFileSize
new2.34 KB

Here's a re-roll with updated member variable and method, plus added more appropriate documentation comment.

dsnopek’s picture

Status: Needs review » Reviewed & tested by the community

Thanks, 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

  • dsnopek committed b860aa7 on 7.x-1.x
    Update Panopoly Test for #2293745 by mglaman | dsnopek: Investigate why...
dsnopek’s picture

Status: Reviewed & tested by the community » Fixed

Committed! Thanks, @mglaman, for all your hard work on this!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.