Change Travis build to run with specific ICU version #14259
Comments
|
Tagging this as "Critical" since at the moment bugs go undetected. |
|
Do you have a specific list of the extensions needed by Symfony right now? Because by compiling PHP we need to compile all the other libraries that don't come with it by default, don't we? |
|
Can't you create a zipball of the PHP binary you want and download/execute it directly in your travis-ci config? |
|
@tgalopin I don't. In my dev environment, I mostly use the standard configuration. @Pierstoval That could work. Do you want to work on that? |
|
@webmozart I'm really sorry but I'm sadly not familiar enough with compilation with sources for this kind of work, and I'm afraid it might take too much time for a "compilation-neophyte" like me to do it, admitting that I do it without any error... 😕 I'm gonna share this problem in different networks and let's hope we find a pro that can do it 😄 |
|
Maybe Travis not the right option here? I know https://circleci.com/ supports docker images which give you much more freedom. If you make your own image its possible install a specific PHP version with a newer ICU version. At least for this case as 1 container is free, but multiple costs more. |
|
I like the Docker approach as it will also be possible for anyone to run the tests on their laptop with the same configuration as the CI. As an added bonus, it also becomes much easier to provide support for third-party deps (like testing sessions on Redis and the like). |
|
Well, providing our own imageS for CircleCI (we probably need several ones as we need several PHP versions) would involve. And maintaining them would mean much more work for us (which is currently done by our CI platform), as we would have to update them regularly for PHP updates. Note that we cannot change the ICU version used by our builds on Travis, unless we compile PHP from source on each build instead of using the version installed by Travis. They don't run the PHP compilation on the worker at the beginning of the build, but every 2 months when upgrading their VIM images. So there is no configuration setting to change PHP options. |
|
👍 for opening a feature request directly to Travis-CI, I think it's the best possible solution, and certainly the "cleanest" |
|
The libicu-dev package (as opposed to the approach to install from source above) is installed on the Travis nodes. As they currently still run Ubuntu 12.04LTS ATM, you're getting 4.8. As soon as they start rolling out 14.04LTS you'll get a newer ICU version through. The alternative would be to change the Chef recipe to build ICU from source rather than using the package... If they are open to the latter, give me a shout! |
|
We don't have to compile PHP on every build, deb packages can be compiled beforehand for a certain version of ubuntu (or even self containing builds, which only requires libc and no other external dependencies) and just install them on the build machine. But it definitely would be a lot of work to do. There are official docker images for different versions of php https://registry.hub.docker.com/_/php/ . They have a minimal extensions installed by default 5.6/fpm/Dockerfile#L39-L48 but there are handy scripts to compile extensions easily https://github.com/docker-library/docs/tree/master/php#how-to-install-more-php-extensions |
|
Using Docker was just a suggestion ;) we don't have to run all the tests using CircleCI but only those tests which need a specialized PHP installation. With TravisCI you have 3 concurrent runs, with CircleCI only one (for the free plan).
Redis is already available on TravisCI http://docs.travis-ci.com/user/database-setup/#Redis |
|
@sstok AFAIK, Travis gives you 5 concurrent jobs (per repo owner, meaning this is shared between the code and the doc) |
…ver possible (stof) This PR was merged into the 2.3 branch. Discussion ---------- Remove skipping of tests based on ICU data version whenever possible | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Many tests being skipped based on the ICU data version don't actually need it. They might be testing code paths not relying on Intl, or not performing assertions on the values depending on the ICU data and so not dependant on the exact ICU version being used. this is somewhat related to #14259 as it allows to reduce the number of tests not running on Travis. Commits ------- 7994513 Remove skipping of tests based on ICU data version whenever possible
…ver possible (stof) This PR was merged into the 2.3 branch. Discussion ---------- Remove skipping of tests based on ICU data version whenever possible | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Many tests being skipped based on the ICU data version don't actually need it. They might be testing code paths not relying on Intl, or not performing assertions on the values depending on the ICU data and so not dependant on the exact ICU version being used. this is somewhat related to symfony/symfony#14259 as it allows to reduce the number of tests not running on Travis. Commits ------- 7994513 Remove skipping of tests based on ICU data version whenever possible
This PR was merged into the 2.3 branch. Discussion ---------- Add appveyor.yml for C.I. on Windows | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | YES, both on Travis (Linux) and on Appveyor (Windows)! | Fixed tickets | #13934, #15049, #14259, #15045, #15444 | License | MIT | Doc PR | symfony/symfony-docs#5654 - testing two matrix lines: - one without mbtring nor fileinfo nor intl - one with these ext enables, intl version 51.2 so that almost no test is skipped on our Intl component - bug fixes thanks to these harder testing conditions - some display bug on appveyor, [reported here](http://help.appveyor.com/discussions/suggestions/197-support-ansi-color-codes). Commits ------- ea5d656 Windows and Intl fixes 8bbd8d9 Add appveyor.yml for C.I. on Windows
|
great work |
Symfony has various tests that rely on the intl extension to be present. These tests are run only if a certain of the ICU library is compiled with the intl extension (see IntlTestHelper). If not, these tests are skipped. The reason is that we otherwise have volatile tests that succeed on a system with ICU 51, but fail on another using ICU 49 (for example).
Our problem is that Travis CI uses ICU 4.8 (see Travis output), hence the intl tests are not executed on Travis, which leads to undetected test failures (see #14256).
We should change the Travis build to compile PHP with a specific ICU version. Ideally, we'd use ICU 55, which is the latest stable version. However, I think that someone who's more familiar with Travis and its configuration/related technologies than I am should work on this.
Information needed to compile PHP with a custom ICU version: The ICU versions can be checked out here: http://source.icu-project.org/repos/icu/icu/tags/
cd source./configure --prefix=$(pwd)/../build(sets a custom install dir)make(build)make install(install to "build" dir)Now that ICU is built, you need to run PHP's "configure" script and point it to the build dir:
In the case of Travis, the --enable-intl switch is already there, but the --with-icu-dir switch is obviously missing: https://github.com/travis-ci/travis-cookbooks/blob/master/ci_environment/phpbuild/templates/default/default_configure_options.erb
Who can work on this?
The text was updated successfully, but these errors were encountered: