PDF tests cannot be tested on Travis

[johnbillion]

PDF support is not available on Travis, so the tests in the Tests_Image_Functions class that rely on PDF support get skipped.

Example output:

3) Tests_Image_Functions::test_wp_generate_attachment_metadata_pdf
Rendering PDFs is not supported on this system.
/home/travis/build/aaronjorbin/develop.wordpress/tests/phpunit/tests/image/functions.php:367

What needs to be installed on Travis to get this working?

Should it be installed as part of the test bootstrap? Any other suggestions?

[danielbachhuber]

Related ​https://github.com/wp-cli/media-command/issues/7

[kirasong]

Yes, agreed, we should be testing this on Travis.

For PDF support to work, GhostScript, ImageMagick, and Imagick are necessary.

In theory, any other stack that results in Imagick/Imagemagick returning support for PDF rendering should also work with WordPress, but that stack is the one at most supporting hosts.

I suspect @danielbachhuber has pinpointed the Travis specific issue, but if those are not all available on the versions other than PHP 7, that's what will need to be installed, if it's not installed already.

[desrosj]

Install Imagick on Travis builds.

[desrosj]

I was able to get Imagick to install on PHP 5.4+ in Travis (version 3.4.3 of Imagick requires PHP >= 5.4). Looks like ImageMagick and GhostScript are already installed on the Travis images.

You can see the build for this patch here: ​https://travis-ci.org/desrosj/develop.wordpress/builds/225468364

There is only one failure in Travis when Imagick is installed.

There was 1 failure:
1) Tests_Image_Editor_Imagick::test_image_preserves_alpha_on_rotate
Failed asserting that 1.0 matches expected 0.0.

For context, when running phpunit --group wp-image-editor-imagick locally using VVV, there are currently 14 tests with 43 total assertions.

[johnbillion]

I'd be happy enough to get the Travis tests running on newer PHP versions without worrying too much about 5.2 or 5.3.

[joemcgill]

Thanks @desrosj for taking a crack at this!

Replying to johnbillion:

I'd be happy enough to get the Travis tests running on newer PHP versions without worrying too much about 5.2 or 5.3.

I agree. With a few exceptions, our Imagick tests shouldn't really be specific to PHP version, so I'd be happy to have 2 of our versions (one older one new) running with Imagick installed so we catch most of the issues. If we find this isn't sufficient, we can reevaluate.

[desrosj]

I can make adjustments to the patch tonight and I will try to figure out why that single test is failing on Travis but not locally.

How far back would we look to backport this, if we would? I could also prepare patches for each version branch that we desire this to be added to.

[desrosj]

Updated patch installs Imagick only on the PHP 5.4 & 7.1 builds. I still can not replicate the failing of test_image_preserves_alpha_on_rotate() test locally, though.

Updated build: ​https://travis-ci.org/aaronjorbin/develop.wordpress/builds/225836970

[johnbillion]

It appears that the failing test_image_preserves_alpha_on_rotate() test is due to the old version of ImageMagick which gets installed on Travis, due to everything running on Ubuntu 12.04.

Following @gitlost's ​example for the wp media command, I've ​gotten a branch that installs a newer version of ImageMagick and the image tests which use ImageMagick now pass. Work in progress still.

[johnbillion]

One concern I have is that it looks like ImageMagick doesn't retain download for older versions. For example, the download for version 6.9.8-3 has already been removed and replaced with 6.9.8-4. cc @gitlost.

[johnbillion]

Latest patch which installs ImageMagick 6.9 and Imagick when running PHP 5.4+. All tests pass.

My only concern remains whether or not the ImageMagick package for 6.9.8-4 will disappear when 6.9.8-5 or 6.9.9 is released and cause the build to fail.

[johnbillion]

Passing build: ​https://travis-ci.org/johnbillion/develop.wordpress/builds/227602927

[gitlost]

Good stuff! I suppose for the disappearing release issue one could set the ImageMagick release to download from the site eg

IMAGEMAGICK_VERSION=`curl https://www.imagemagick.org/download/releases/ | grep 'href="ImageMagick-6.9.8-[^.]*.tar.gz"' -o | grep '6.9.8-[^.]*' -o`

A further consideration is which release to use, as using the latest and greatest isn't what's out there in the field, so it might be better to try to use the lowest one can get away with or something...

[netweb]

I'm not that familiar with ImageMagick, though Travis CI includes it in their docs that it's available as a library for Ubuntu 12.x builds ​https://docs.travis-ci.com/user/ci-environment/#Libraries

Happy to dig around further and/or ask Travis CI for more info if that'd be helpful

[johnbillion]

Yeah it's available but it's an older version (6.6.x) as I mentioned in comment:9. AFAICT this exhibits the bug that causes test_image_preserves_alpha_on_rotate() to fail whereas 6.9.x doesn't.

Could do with some more testing, but that's where I've gotten so far.

[gitlost]

After setting up a Precise virtualbox locally, traced test_image_preserves_alpha_on_rotate back (laboriously) to failing on ImageMagick 6.6.9-10 and working on ImageMagick 6.7.0-10, so it's an ImageMagick bug, perhaps connected with ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=18900, though it's hard to tell with old pre-git ImageMagick stuff.

I couldn't reproduce the media-command behat seg faults, which was disappointing, but typical for memory bugs I suppose.

See ​https://github.com/gitlost/wordpress-develop/pull/1 for a version that runs Imagick for all PHP versions, with a variety of ImageMagick versions ranging from 6.5.4-10 to 6.9.7-10, chosen to hit various issues and cover some of the hoary versions out in the field as mentioned in eg #36534. It skips test_image_preserves_alpha_on_rotate if the ImageMagick version is < 6.7.0-10, and skips various ImageEditor tests for PHP 5.2 that use ReflectionProperty::setAccessible().

[netweb]

Related: #41148 Test for ticket 39875 can throw PHP error

[danielbachhuber]

I ran into this bug (and a variety of error notices) in the wild on a DreamPress box. Here's a summary

3) Tests_Image_Intermediate_Size::test_get_intermediate_sizes_by_name
ImagickException: exif_read_data(waffles-1.jpg): Incorrect APP1 Exif Identifier Code
/home/wp_5xude7/wp-test-runner-35/src/wp-admin/includes/image.php:430
13) Tests_Image_Meta::test_utf8_iptc_tags
ImagickException: exif_read_data(test-image-iptc.jpg): Illegal IFD size
/home/wp_5xude7/wp-test-runner-35/src/wp-admin/includes/image.php:430
/home/wp_5xude7/wp-test-runner-35/tests/phpunit/tests/image/meta.php:126
14) Test_Image_Resize_GD::test_resize_bad_image
ImagickException: imagecreatefromstring(): Data is not in a recognized format
/home/wp_5xude7/wp-test-runner-35/src/wp-includes/class-wp-image-editor-gd.php:102
/home/wp_5xude7/wp-test-runner-35/src/wp-includes/media.php:2913
/home/wp_5xude7/wp-test-runner-35/tests/phpunit/tests/image/resize.php:168
/home/wp_5xude7/wp-test-runner-35/tests/phpunit/tests/image/resize_gd.php:32
16) Tests_Image_Editor_Imagick::test_image_preserves_alpha_on_rotate
Failed asserting that 1.0 matches expected 0.0.
/home/wp_5xude7/wp-test-runner-35/tests/phpunit/tests/image/base.php:64
/home/wp_5xude7/wp-test-runner-35/tests/phpunit/tests/image/editor_imagick.php:531

Full report in: ​https://gist.github.com/danielbachhuber/f6f3711c877350ad610e569c0ba9931e

[wp581415]$ convert --version
Version: ImageMagick 6.6.9-7 2016-06-01 Q16 http://www.imagemagick.org

It'd be good to get ImageMagick running in Travis so we have visibility into these sorts of failures.

Related ​https://github.com/octalmage/WP-Unit-Test-Runner/issues/19

[danielbachhuber]

Replying to danielbachhuber:

I ran into this bug (and a variety of error notices) in the wild on a DreamPress box.

As it turns out, the box is running Imagick 3.4.1 and thus suffers from this issue ​https://github.com/mkoppanen/imagick/issues/147

[peterwilsoncc]

With the switch to Docker in [45762], does this become easier?

[noisysocks]

Replying to peterwilsoncc:

With the switch to Docker in [45762], does this become easier?

Potentially! I created ​https://github.com/WordPress/wpdev-docker-images/issues/10 to track adding Imagick to the docker images we're now using.

[pento]

Imagick (as well as ghostscript and exif) are ​now in the Docker images, so all of these tests run and pass.

Here's a recent build that I restarted to use the new images: ​https://travis-ci.com/WordPress/wordpress-develop/builds/123629258

Since there's nothing to change in Core, I'm going to close this ticket.

[johnbillion]

#40536 was marked as a duplicate.