On Travis-CI we're using the builtin in PHP webserver (rather than Apache or nginx) which support Clean URLs for normal paths, but fails to generate images from images styles (404 is returned, rather than generating the image on the fly).

This breaks tests that need valid images from image styles in order to work!

NOTE: At the moment, there is only one such test in livepreview.feature (from #2398347: Panopoly Magic abuses FPP revisions), but I could see the need for verifying that images are valid in other tests as well.

There are two options:

  1. Ideally, drush runserver would be updated to allow images styles to work with Clean URLs:

    https://github.com/drush-ops/drush/issues/1189

    But I can't see an obvious fix in the drush code, and I don't know when someone more knowledgeable will be able to help out. :-/

  2. There is the issue about running our tests through Apache or nginx, which would fix it, but I'm not yet sure this is actually a good idea: #2183021: Should Travis-CI use Apache/nginx rather than the builtin PHP webserver?

Anyway, once this is fixed, we need to re-enable the test in livepreview.feature!

Comments

Anonymous’s picture

Just a note: nobody uses built-in PHP server for production so using a different environment setup for testing makes basolutely no sense.

dsnopek’s picture

Just a note: nobody uses built-in PHP server for production so using a different environment setup for testing makes basolutely no sense.

That's definitely one pro of using Apache or nginx to do testing! It's mentioned on the issue specifically for that: #2183021: Should Travis-CI use Apache/nginx rather than the builtin PHP webserver? (which is probably the most appropriate place for this discussion)

That said, I do think it makes some sense to use the PHP webserver. :-)

While right now our build/test scripts only run on Travis-CI, I'd like to break them into smaller pieces, some of which could be run on a developer's system. By using the PHP webserver, we could have a script that could setup the whole environment, including the webserver, without needing special permission (which we'd probably need to setup Apache or nginx).

That said, we haven't done any of that work yet (and might never find the time to do it) so it's not a very strong argument in favor of the PHP webserver. But I just wanted to point out that I think saying it "makes absolutely no sense" is kind of extreme - there are pros and cons to both approaches. Let's continue to discuss them on this issue: #2183021: Should Travis-CI use Apache/nginx rather than the builtin PHP webserver?

dsnopek’s picture

Supposedly this PR for Drush will fix the image generation issue:

https://github.com/drush-ops/drush/pull/2501

I haven't had a chance to test it

dsnopek’s picture

Status: Active » Needs work
StatusFileSize
new488 bytes

Here's a patch that will use Drush from that PR on Travis. This isn't really committable as-is, but it'll provide a basis for testing that PR on Travis

dsnopek’s picture

A travis build with the above patch passed:

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

And even showed screenshots with the images loading:

http://i.imgur.com/LLN0kpf.png

(Behind the pop-up, in the WYSIWYG, the Panopoly logo there - it was a broken image in previous builds)

dsnopek’s picture

Ok, to get this committed we need to:

  • Make our own fork with the changes from the above PR so we have control over the code and to make sure were on the latest version of the Drush 8.x upstream
  • Uncomment out the "Previewing an image widget should show a valid image" test in livepreview.feature -- it actually depends on the image styles working, so we'll increase our live preview coverage and make sure that image styles are working at once :-)

Both those things should be relatively easy to do!

dsnopek’s picture

Status: Needs work » Needs review
StatusFileSize
new489 bytes
new2.75 KB

Some patches to test!

EDIT: Here's a Travis build: https://travis-ci.org/dsnopek/panopoly/builds/227705565